I’ve been using (and loving) syncthing for about 4 months now, but I’ve run into an issue that I can’t resolve. I have about 25 folders syncing and two of them are stuck in an endless Scanning / Out of Sync loop. The folder status shows Out of Sync and flashes Scanning for about half a second every second, ad infinitum. The two folders that are failing are doing so only on specific items, and any other files that are changed in the folders are continuing to sync.
Clicking on the items left to sync lists that item, with no downloading progress bar, just the “Sync” status on the left, and the file size on the right.
Within explorer on the failing side, there is a temp file “~syncthing~FILENAME.EXT.tmp”
Things I’ve tried:
-restarting both sides of the client
-deleting the temp file on failing/receiving side, restarting
-manually placing the file on the failing side
-deleting the folder listing on the both sides, which initiates a full rescan
Any ideas? Thanks!
The release you are currently running, unintentionally hides errors (if you don’t have Failed items in the UI), that is due to be fixed sometime soon.
Try running with STTRACE=model env var, which will print more debug info.
Ok, it’s hard to parse all the output since I have so many folders, but I think I’ve grabbed the relevant info:
As an aside, is it unnecessary to redact so much info? I’m unsure which is sensitive from a doxing standpoint. Thanks.
It seems that you haven’t scanned your folder, or that file is constantly changing, hence technically cannot be brought in sync.
Hmm, it seems unlikely that the file/s are changing. They were created about 3 weeks ago and haven’t been touched since. Some of them are just jpegs. On the sending side, which is behaving correctly, the folder status is “Up to Date”. On the receiving side, I’m getting that constant flicker of Out of Sync/Scanning.
Anything else to try?
Well the one stuck doesn’t seem to be a jpeg, sdlprt
I am fighting this same issue right now. What seems to work is doing this on the sending side:
- Move the file(s) in question out of the sync folder.
- Rescan the folder - wait until this is finished.
- Check that Global State shows same number of files on both send and receive end.
- On the receiving side, delete any .tmp or other files leftover.
- Move the file(s) back into the sync folder.
- Rescan the folder again.
The receiving computer should now properly sync that file.
Yes, the example file isn’t a jpeg, but there are several files affected by this issue, and some of them are.
ninja6o4’s process has fixed the syncing! I did a slight variation where I zipped the failing files and then deleted them, re-scanned, deleted the temp file on the receiver, and then unzipped on the sender side. Worked a charm, thanks!
Still not clear why the issue occurred or how to avoid in the future, but hopefully there isn’t a recurrence.
That shouldn’t happen though. Are you using inotify? This would imply the rescan is not working.
v0.14.38, Windows (64 bit)
That doesn’t answer my question, on whether you are using inotify.
Can you run with STTRACE=scanner,model and provide a bigger full log somewhere?
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.