Dear Madame and sir!
I am using syncthing for quite a while now and what really annoys me is that syncthing does not sync symlinks under Windows. I just want to replicate the Content of the symlink, it should be treated as a normal Folder.
Best regards, thejack
Hi thejack,
This came up many times before. The problem is, that there never was a solution that was both user friendly and save (as in not loosing data). See #1776 and #3387 (there is probably more on the forum on this topic).
And, as of next release, symlink support on Windows is removed entirely. It was broken for like a year or something and no-one noticed.
could this be the reason, why all the symlinks on my windows machine are now overwritten with “real” folders ? (and therefore my harddrive fills up with lots of dupes)
or is this* just the “normal” (broken) behaviour, which I can’t remember to be so rude the last year(s).
(using v0.14.23 on mac and windows)
*this: I created a folder (A) with some symlinks on my win64 machine. The synchthing-folder has r/w access to folder (A) containing all the symlinks. Having shared that syncthing-folder to a mac device (r/w) resulted in overwriting all the symlinks on the windows machine, with “real” files and folders. thus, reducing my diskspace radically.
We take great care to never follow symlinks. This requires more care than you’d expect as symlinks on Windows are inherently completely broken (in my opinion, obviously). For example, if you create a “directory” symlink to .., and do a dir /s on Windows, it’ll recurse until it crashes.
v0.14.23 will still attempt to sync and maintain such symlinks, while future releases will take a more “what is this I don’t even” approach and not even try. In no cases should the symlink be replaced with what it points to, though.
Hi,
I need to migrate a Jenkins server from Windows to Linux, taking all job configurations and build history with me on the way. My first attempt in copying the data over was with cwRsync. This was able to copy everything incl. symlinks (Jenkins uses them to mark last failed or stable builds, for example), but due to the sheer amount of data, this approach wasn’t feasible.
Since I also use SyncThing for other things already, I tried this approach, only to find out that symlinks are not supported on Windows, which I can’t understand. They just work fine, and, as the rsync example above shows, they can even be reproduced on Linux.
I also can’t reproduce the “dir /s” example you mention. There’s no recursion whatsoever, on both Windows Server 2008 R2 and 2012 R2.
So, I grabbed the ST sources and modified them to support Symlinks on Windows, and it’s working just fine, at least for my use case.
Sorry, didn’t read the “recursion” part properly and didn’t recognize the “..” thing. Didn’t test that, of course. But who would create such links anyway? 
My solution to this was to resolve the symlinks on the source using bindfs. It is a FUSE filesystem that has an option resolve-symlinks which makes all symlinks look like the target file or directory. Hope that helps!
Keep in mind this means that I, on the other side, can create a symlink foo -> /etc. That’ll sync to your side, be created as a normal symlink, and then presumably get resolved by bindfs at some point. Syncthing on that side will then see the “directory” and give me back the contents of what I pointed to. Replace /etc with ../Documents or /home/alex/.bitcoin-wallet or whatever scares you appropriately. 
As a new user, with zero cred, I figured that I’d weigh in too.
The local symlink to /etc overwriting a remote /etc is a permissions issue. There’s no one to blame for things gone horribly wrong with that, and at the same time, it isn’t really syncthing’s responsibility to reduce functionality to protect people.
Regarding filesystem loops; I have several on my Win 7 machine, and it has never crashed over them. But there are enough OS functions available and few enough symlinks in the the universe, such that detecting and preventing insertion of a file system directory symlink loop is a tractable solution (and logging the error, as others are logged).
secondly, a lot of the recursing, out of path monitoring, and duplicates issues can be resolved using the local realpath implementation, along with some md5 hashing.
Thats my <2cents.
Not necessarily…
Sure there is: the attacker for attacking, and Syncthing for allowing random files on the file system to be requested…
You weren’t around during the headache which was trying to get symlinks working in a way which didn’t have fundamental issues, didn’t randomly break, and didn’t prompt numerous (if I’m remembering correctly) security reports from (thankfully) ethical security researchers, and the associated speedy patches and “Please everyone upgrade now it’s important” announcements.
If you’re on Windows then all this is moot, as you need admin privileges to create symlinks, iirc.