After archiving the data in the reported infinite recursion paths, and deleting the directories/files, no recursion were anymore reported. I have upgraded successfully to 1.7.
But… I still think that THIS is a dangerous feature. Because of the data loss that can occur. I’m sure that there are cases where one will leave trustfully the data management in the hand of Syncthing, and will not check/see the error, either on webpage or log itself. Only with, “It prints a warning and stops descending”, could just go unnoticed. Syncthing will just have to STOP and quit any activity, once such infinite recursion paths are to be found, to prevent unexpected deletion. It’s the user side responsibility to ensure that the underlying filesystem it’s in perfect shape.
For the moment, I will keep using Syncthing in one-way only setup.
Thank you for all the support and provided answers.
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.
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.