Sometimes I’m transferring a bunch of files to a storage device monitored via watcher by syncthing. While these files are transferring, scanning usually starts, and inevitably there are a few “failed items” for files that were mid-transfer when the scanner scanned them. (File changed during hashing). This is all reasonable.
However, when this happens, it seems the scan is interrupted and none of the files are transferred. Of course, after some period of time, the rescan happens, and the files go.
But does it make sense none of the files went, and the rescan didn’t happen right away? I waited a few minutes and it didn’t restart, well after all the inbound transfers stopped.
Is there some advanced setting somewhere that controls this behavior?
It would be great if the scan completed, and perhaps the scanner went back to the failed files after scanning complete… Oh and the successfully scanned files sent right away.
It does seem when there are failed items this way, no progress is made until the next scheduled scan interval which kind of defeats the purpose of the watcher.
That shouldn’t be, as when the transfer progresses that triggers more events picked up by the watcher. So it should be scanned again and again, failing until the transfer is done, then succeeding. If you observe something else, enabling watchaggregator and scanner debug logs would show what exactly is going on from the pov of syncthing.
If the scanner scans 10 files successfully before it hits the scan error, are those 10 files transferred? Or does the scan error some how inhibit them?