[xxx] 2018/01/05 07:16:27 INFO: Puller (folder "Documents" (xxx), file "computer\\Admin-Raspberry\\home\\pi\\Documents\\Greenfoot Projects\\API\\resources\\inherit.gif"): finisher: file modified but not rescanned; will try again later
[xxx] 2018/01/05 07:16:53 INFO: Folder "Documents" (xxx) isn't making progress. Pausing puller for 1h4m0s.
I can read the words “finisher: file modified but not rescanned”, but I don’t know what they mean. This has gone on for several days. How do I fix this so the files get synchronized?
Good news upfront: Despite this error, all other files are still synchronized.
This means that the file to be overwritten is different from what Syncthing expects from the database, so it wont be overwritten until it is rescanned (which should happen right after this error is printed). The fact that this happens several time for you means that this doesn’t happen. Prime suspect for this are case conflicts: Windows is case insensitive, Syncthing is case sensitive -> that is a known (unhandled) issue. So check the path (also on other machines) for files which only differ in case. Given that you have macs (generally case sensitive) and windows in one cluster, I assume this is the issue. If it isn’t, we will probably need debug logs.
Do you have non-windows devices in your cluster? The only reason for this that comes to mind are conflicts of case in the file path on another device (e.g. Foo/Bar on win, foo/bar on any of the others). You can probably compare the path as given in the log to the path on windows and if you find any case differences, that is the cause. The solution is to rename it (on the other device) to something different (as in not only differing by case). If that’s not the case, then logs with model and scanner debug facilities would be a first thing to check.
In my case, it wasn’t the files themselves, but a directory above the files (that had a mismatched case).
I understand your file have been unchanged and untouched or months. The parent directories, too? On a wild shot guess, could it be that the directories or files are being changed on the other peer sync computers and the error shows up on an innocent computer?
To debug, pick one error filename and check the full path and filename for any differences in case. Any difference?
In my case I found a difference and the error messages went away when I manually corrected the one errant directory to identical case.