Ok ok ok, now I understand. No problem but if too many files maybe the download could before the complete scan if done. Automatically, not a user choice.
Thanks a lot !
Ok ok ok, now I understand. No problem but if too many files maybe the download could before the complete scan if done. Automatically, not a user choice.
Thanks a lot !
Hello, would it help to pause synchronization before moving or renaming many files and then resume synchronization only after the new situation is fully indexed ?
Potentially, but pausing the device not the folder. Still, indexes are sent in the order they are scanned, so itās still not guaranteed. There are some features that try to make sure this works better, but I think itās still not guaranteed.
Why is it rescanning then?
Is there a zero-complication method from the cli simply using a direct call to syncthing that would enable riskless moves?
i.e.
syncthing cli mv
or something?
Would this be possible?
Everything else sounds like tricks and hopeful thinking but basically unsafe (network or huge scans).
No, there is nothing like that, and I donāt think it makes sense to add that.
If you are running some special command to move files you might as well ssh host mv file
What about a check box in settings? For users who donāt care about speed, and can afford to let the entire scan finish before downloading starts, I mean.
This is an ancient long thread at this point, you need to be more clear what the checkbox is for.
A checkbox to change the default behaviour. Let the entire scan finish before starting the file transfer process. To avoid this:
If there are a thousand files to scan, information about the first 100 might be sent out while weāre still scanning the remaining 900, and those 100 start downloading while weāre still scanning ā before weāve come to the part where we notice that 1000 files were also removed and this was all a rename.
A scan can finish in the middle of you moving a thousand files though, thereās no indication to Syncthing when the user is ādoneā doing something, other than maybe waiting several minutes after a change before acting on it.
Oh. Can Syncthing not detect that there are changes being made to watched folders, thus resetting the āwatchā timer back to the 1 min default, or whatever the user has set?
Syncthing does precisely that. The timers are in the config (āfs watcher delayā under the advanced folder settings). Thereās even a specific multiplier for deletes, to add an extra delay when a delete is detected to make sure we find the possible destination it was moved to.
Oh. Then I donāt understand what it is about the OPās described scenario that makes Syncthing start transfers despite an ongoing scan.
From whatās been stated here, there is a pretty solid coverage of different possibilities.
Does OP have extremely large files, like several GiB in size? Iām assuming they might take longer than the default 1 min to be processed?
Scroll up and youāll know everything we know, from the original conversation back in 2019. Asking follow up questions about it today is unlikely to bring anything new to light.