Keep in mind though that the root cause here is a filesystem extension doing something really odd. Syncthing surfaces this oddness, but it’s simply using the Windows APIs as they are designed and suffering from the filesystem effectively lying. That things appeared to work previously is nice, but I would be worried about what’s going on behind the scenes at the filesystem level.
There is a problem that we return no error from the scan when this happens tho, which in case of the poor filesystems that invent different file ids a lot of them being duplicate on different scans might lead to us deleting files. The files will probably come back on next scan, but I wonder if the recursion should be a scan error instead.
Hi, I’ll step in.
In previous versions of ST, directory junctions were not synchronized at all, so no data loss should occur, IMO.
If ST stopped with error on first detection of infinite recursion loop, one wouldn’t be able to synchronize e.g. the user profile folders - there is an in-built infinite recursion there (in <userprofile>\AppData\Local\Application Data).
Switching off the infinite recursion check is not an option, that could crash ST. The only possible option would be to turn off the directory junction traversing, i.e. return to the pre 1.7.0 behaviour, perhaps using a checkbox in advanced settings.
Edit: I think (but have not tested) that you might also prevent infinite recursion on a particular directory using .stignore.
The issues above are not specific to junctions, though. Granted there are weird filesystem shims involved that lie about the file IDs, but that triggers the inifinite recursion detection without there being infinite recursion, in effect rendering some files invisible to Syncthing and hence liable to get deleted remotely or otherwise mishandled. Turning this into an error condition seems correct.
Actual recursion should be correctly handled by ignores, I think. Except perhaps not in the filesystem watcher case?
If this will be turned into error, it’s important to consider whether ST will be able to recover from the error state when the errors get resolved. I have permanent issues with out-of-sync items, locally-changed items, devices in permanently 95% synchronized state etc. where there seem to be no working ways to recover from the issues.
Yeah those issues, whatever they are, are different.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.