I’ve made a DRAFT implementation using an advanced folder option to “follow symlinks”. Please bear in mind that I’m not familiar with go. So questions like “why is it like this, could be more efficient” would be welcomed tips for me.
I cannot do the “risk management” in this concept I’d like to - at least - show to you. But I think it’s not very risky if one side decides to set the “follow symlinks” folder option, preferably together with a sendOnly folder.
I’m starting with node A in “normal Syncthing mode” where symlinks are ignored on Windows.
For the folder “symtest” on A I get:
I’m connecting node B and sharing the folder with him: So B gets…
Now I’m turning my newly implemented option “follow symlinks” on for the folder “symtest” on A and make it sendOnly - for safety reasons - but could also have chosen sendReceive.
Node B is now receiving everything “behind” the symlink “3” correctly.
If I revert the option “follow symlinks” on A back to off. B will get the folder “3” removed again and the state of both nodes falls back to 16 (initial state from the beginning).
Again, I hope for the help to get this somehow clean to Syncthing. From my “data security” view, it’s nothing else you can burn your fingers like for example nasty ignoreDelete’s and ignorePermission’ settings users could set in a multi node cluster and then make some ignores versus unignores until they loose their data.
My implementation is not best from view of coding, sure, but please consider it as a sensible approach to make symlink’s possible in Syncthing on both Windows and Linux if admin users really need them. If unexperienced users would use this implementation, they would a) not know they could set “follow symlinks” and b) the one experienced user having reasons could well use it to help.
This would ease my syncs a lot as I’ve got a lot of folders with no common root and the ZFS filesystem which does not support mount --bind. Having copy jobs preparing a duplicate dataset “just for syncthing” is not nice but bearable at the moment. I’d be happy to help here.