Maybe leave the setting as-is for existing configs, and only apply disabled-by-default to new configs? That would minimize the risk of breaking existing setups. That would of course mean that all current setups would have it on, but I guess most people affected have already worked around any issues (with ignores).
1 Like
We have seen funny filesystems blow up with recursion errors too, so I guess it should be an off switch for both. There are also cases where even on normal filesystems we might trip over the recursion check, because for example ReFS uses 128 bits for identifying filesystem tree entries, yet OS apis only return the last 64bits…
Also, I am not sure if we want this to be an off switch, I think we want this to be an on switch instead?
Yeah no, that’s too scary.
Nice, so now we have to either keep it default enabled, letting it cause problems in the future too. Or the change is going to be more complex than the original feature. Something like exposing junctions on fs.FileInfo and scanner invalidating files behind junctions instead of marking them as deleted. Default enabled it is (unless someone is motivated to do something nice): lib/config, lib/fs: Make junction behaviour configurable (ref #6606) by imsodin · Pull Request #6907 · syncthing/syncthing · GitHub
A switch sounds good to me. For me, the junctions are a great improvement on Windows. But yes, I think the “normal user” is not able to setup ignores when he first tries out Syncthing coming from somewhere else and still needs to discover and learn.
In my opinion “default ignores” would be a nicer approach because we know that it’s mainly %userprofile%\KnownSystemJunctionFolder causing the cosmetic problem. If we could detect “user creates a new folder with %userprofile% as root” we could then ship those ignores.
Update: Not a good idea as Microsoft made those folder names localized 
So instead of filtering for the folder path on creation and auto-turning the junction follow off a default to off would be better. It could also be called “junction strategy: ignore” on the UI (like Duplicati has it).
I can’t tell my following this thread, is this feature request dead?
It’s implemented ages ago.
Is it a setting? Because I can’t find one and it’s not working for me. I am a returning Syncthing user, I used it years ago and trying to see it will work for me to replace Resilio.
This has been cooking for a long time and each attempted implementation has run into unanticipated difficulties. Given that and the theoretical difficulties of ensuring correctness in the presence of (followed) symlinks I’ve decided that following symlinks will not be implemented. I’m also locking this issue because I don’t want followup arguing about in the bug tracker. Anyone is welcome to argue about it on the forum, but unless the argument is backed up by a foolproof implementation it’s unlikely to have a positive outcome. Sorry, peeps.
I just realized, that is your reply @calmh. Is this thread not the same thing?
There’s a new advanced folder setting “Junctions as dirs”. The feature and it’s issues are discussed (in part) in this thread. The feature treats Windows directory junctions like a “normal” directory.
Oh, I was looking in the wrong place, I found it.
I enabled it for a test folder with a Junction Point in it, but that is not working.
Enabled for directory Temp. Added Junction Point to Temp2.
Not syncing:
Are you using the newest version of Syncthing? In one of the previous ones, there was a bug that required you to restart the program in order to “see” the junction points.
I just downloaded it: v1.18.0
Well, yea, it required a restart.
To be specific, it does not require a full restart, but it does require the folder to be paused and resumed to trigger.
For reference:
https://github.com/syncthing/syncthing/issues/7371 https://github.com/syncthing/syncthing/issues/7850
1 Like
Hi,
I see the latest posts are from 2021. Is the “follow symlinks” feature available in the latest ST for Windows, or only in future beta vesions? Thanks
Congrats again for this great project.
PS: I see @calmh mentioned in Option to follow directory junctions / symbolic links? - #134 by calmh that it is implemented, but when I tried to add a symlink to another directory (created with mklink /d ... ... on Windows) in a Shared folder, the other computer did not sync it.
This is a long thread. Despite the phrasing of the topic, the only thing that is implemented is following junction points. Symlinks are not followed and there are no plans to ever do so.
@calmh Thank you for your answer.
On Windows, I tried with a junction and it works now, if and only if I set <junctionsAsDirs>true</junctionsAsDirs>.
Minor drawback: any change in the directory which is linked with a junction is not automatically detected by the FSWatcher. I have to do a “Rescan all” in the GUI each time I want to sync the modifications inside the junctioned-directory to the remote computer.
Is this a known “in-progress” feature, or just a wrong configuration on my side?
Did you restart or pause/unpause the folder? That’s most likely needed, if it works at all. I wouldn’t be surprised if the system library for watching doesn’t automatically handle/follow junctions. And I have no intention to look into making it do so/add workarounds.
After further tests, I confirm that the automatic FS watcher (for new files/file changes) doesn’t look in the junctions directory by default on Windows, as of today (June 2022, ST 1.20.2)
We have to do either:
-
“Rescan all”
-
“Pause all” and “Resume all”
I don’t think that’s necessarily the case. I’ve just done a simple test, and Syncthing was able to automatically detect new files inside the junction with no issues.
Where does your junction point at specifically? Just in case it’s a drive root or somewhere similar, there’s a known issue about the watcher not working there.
Scrap the above. It only worked initially after creating the junction itself (and thus it scanned its subfolders too), but it doesn’t work anymore when doing file manipulations inside the junction.
1 Like