I’m trying to sync a 1.5TB backup-file and it got stuck.
Syncthing (on Windows10 x64) is giving me this in the logs:
[JSUAT] 2022/05/30 13:07:24 INFO: Puller (folder "KEUKEN3 Backup" (zdom6-zadcv), item "File Backup\\File Backup_20220221_Full_v1.pbd"): syncing: insufficient space in folder "KEUKEN3 Backup" (zdom6-zadcv) (d:\Syncthing\KEUKEN3 Backup): current 300.7 GB < required 1.7 TB
[JSUAT] 2022/05/30 13:07:24 INFO: "KEUKEN3 Backup" (zdom6-zadcv): Failed to sync 1 items
[JSUAT] 2022/05/30 13:07:24 INFO: Folder "KEUKEN3 Backup" (zdom6-zadcv) isn't making sync progress - retrying in 35h0m0s.
However, when I look at the folder, it shows:
So, it already pre-allocated that 1.5TB (and it took aaaaggges on that slow drive =)
I’m just not sure why there are now 2 files with the same name, there never really was a version that small. (hmm… well, maybe there was while the backup program was creating it and Syncthing may have started indexing it already??)
I probably can remove both files and have it start over although I was really hoping that the couple of hundred GB it already transferred would not get lost… I may put it on a different drive and folder so it may do the ‘downloaded from elsewhere’ trick?
I’m wondering if there is anything worth testing before I do that? (“for science” =)
This is normal, as Syncthing with file watching enabled by default tries to sync files 10 seconds after they’ve been detected. If the file is still in use (i.e. locked by Windows or other software), it will fail to hash it, and then it will keep trying to do it again later).
If the backup software offers an option to write to a temporary file first, then I’d strongly suggest enabling it (and possibly ignoring the temp file in Syncthing), so that only the final backup file is hashed and synced. Otherwise, you will definitely experience slowdowns when both the backup program and Syncthing try to read and write to the file at the same time.
I suspect this is a bug; when starting to sync a file that is X large, Syncthing wants there to be X bytes of free space available. Though in this case that isn’t necessary, because the temp file is already allocated. In most cases this won’t matter, but in this case since the file is kind of large it does matter.
I also don’t think you can work around this by setting the free space check to zero, unfortunately…
Removing the temp file and hoping that it will then sync in one go might work.
However, if this file ever changes you’ll end up in the same situation when syncing it next time (file exists, and same amount of space needed once more for the temp file).
I was mostly confused about the fact it indeed seems to want the filesize ‘on top’ of the already allocated temp file.
PS: I also found it weird that the log shows the above text but the UI does not mention anything about lack of diskspace. I only noticed because there was no progress.
