I hope this is the right forum for my question. I’m using Syncthing for syncing a large folder across four OSX machines, and everything has been working fine so far. But I recently noticed two cases in which I inadvertently get ‘folder isn’t making any progress’ warnings after some time of running Syncthing (though it’s not always absolutely clear to me when and why this is happening).
The first is when I let Transmission store its temporary partial download files somewhere within the synced folder. Once the download is finished, these temporary files are deleted by Transmission, but Syncthing continues to look for them and reports an error on failing to do so.
The second case is when I use InSync on one of the four machines (but not the others) to sync a subfolder with Google Drive. It’s mote difficult here to pin down what triggers the error. But once it happened that, after I moved some files within the subfolder, Syncthing continued to look for them at the old location, while they were correctly showing up at their new location on my local harddisk and on Google Drive.
By the way, the errors do not go away after repeated rescans. The only way of getting rid of the error message is to manually move the files back to where they were before.
Interestingly, the error did not prevent Syncthing from keeping on syncing all other, unrelated files, though I had the impression that it took longer for changes to propagate across machines.
So, my question is whether there’s something generally problematic with setups like these, and whether they is a way around these problems. I can live without giving Transmission and InSync access to my synced folder, but it would be nicer if I could.
Thanks a lot for any suggestions, and also for your great work on Syncthing - I’m very impressed by its capabilities and ease of use!
So it could be that we notify other nodes about these files, which as a result start downloading the files from us.
Then when the files disappear, they can no longer finish the download, hence throw an error.
All of this should fix itself up and go away after a rescan interval on the machine which is producing the changes, and after a few minutes other machines once they received rescan results from the machine producing the changes so that they are aware of the fact that the file is no longer there and there is no need to try and redownload it.
Obviously having actual error messages would help explain stuff better, as now I am basing my answer on assumptions.
Thanks a lot for the quick reply. Unfortunately, the errors did not go away even after I waited for a whole night. I have the debug log from the last incident, here is a short extract (please let me know if you would like to see more of it):
[TF6QE] 2015/04/01 10:32:14.980066 rwfolder.go:242: INFO: Completed initial scan (rw) of folder Sync
[TF6QE] 2015/04/01 10:32:41.947009 blockqueue.go:43: DEBUG: open: open /Users/Fabian/Sync/Drive/Research/Writings/Waiting/NovelsSounds/.syncthing.Alward.Words.htm: no such file or directory
[TF6QE] 2015/04/01 10:32:41.947764 sharedpullerstate.go:164: INFO: Puller (folder “Sync”, file “Drive/Research/Writings/Waiting/NovelsSounds/Alward.Words.htm”): dst stat dir: stat /Users/Fabian/Sync/Drive/Research/Writings/Waiting/NovelsSounds: no such file or directory
[TF6QE] 2015/04/01 10:32:42.368860 blockqueue.go:43: DEBUG: open: open /Users/Fabian/Sync/Drive/Research/Writings/Waiting/NovelsSounds/.syncthing.Alward.Words.htm: no such file or directory
[TF6QE] 2015/04/01 10:32:42.368968 sharedpullerstate.go:164: INFO: Puller (folder “Sync”, file “Drive/Research/Writings/Waiting/NovelsSounds/Alward.Words.htm”): dst stat dir: stat /Users/Fabian/Sync/Drive/Research/Writings/Waiting/NovelsSounds: no such file or directory
[TF6QE] 2015/04/01 10:32:46.200871 rwfolder.go:208: WARNING: Folder “Sync” isn’t making progress - check logs for possible root cause. Pausing puller for 1m0s.
[TF6QE] 2015/04/01 10:33:45.454567 walk.go:82: DEBUG: Walk /Users/Fabian/Sync/Temporary/Read 131072 &{[] true 0xc208877780 d41d8cd98f00b204e9800998ecf8427e 0xc208100240 {0 0}}
[TF6QE] 2015/04/01 10:33:45.454638 walk.go:354: DEBUG: checkDir /Users/Fabian/Sync/Temporary/Read &{Read 1258 2147484141 {63563400221 0 0x9ae940} 0xc208d5f9e0}
[TF6QE] 2015/04/01 10:33:45.456804 walk.go:156: DEBUG: ignored: .stfolder
[TF6QE] 2015/04/01 10:33:46.609967 blockqueue.go:43: DEBUG: open: open /Users/Fabian/Sync/Drive/Research/Writings/Waiting/NovelsSounds/.syncthing.Alward.Words.htm: no such file or directory
[TF6QE] 2015/04/01 10:33:46.610097 sharedpullerstate.go:164: INFO: Puller (folder “Sync”, file “Drive/Research/Writings/Waiting/NovelsSounds/Alward.Words.htm”): dst stat dir: stat /Users/Fabian/Sync/Drive/Research/Writings/Waiting/NovelsSounds: no such file or directory
The messages about the missing file get repeated again and again about every half a second,
while the messages about not making progress occur every 60 seconds (i.e. every scan interval). This goes on forever (I stopped logging after about 15 minutes). And the same messages occur with respect to all other files concerned.
So if A has removed the file, are you sure that A has rescanned and detected that the file is gone?
Also, it seems that you are somehow getting syncthings temp files from linux being synced by someone else (as we ignore them) onto Windows which is also causing issues?
You shouldn’t nest syncing solutions as you will definitely have problems, or atleast you should tell them to ignore syncthings temporary files.
Thanks! Yes, I even did a manual rescan on the machine where the files were moved.
The machines involved all run OSX Yosemite. I’ll try it out whether it helps if InSync ignores the Syncthing temp files.
But the problem with Transmission occurred, when there was no nested syncing with InSync. Or does the incremental down- and uploading of torrent files have the same effect?
Sorry for the long silence, but I was on holiday. Asking InSync to ignore the Syncthing temp files did indeed do the trick. Now, the ‘making no progress’ messages still occur from time to time, but disappear after a short while. Thanks again a lot for your help - and for your work on this great piece of software!