Syncthing keeps resyncing from the start


I have two Windows 10 PC’s running Syncthing 1.8.0 using the SyncTrayzor wrapper. I am trying to sync a folder with three large files (>2GB each). The amount of time during which both PC’s are online is limited, so I can only transfer about 200 to 500 MB each time. Now sometimes the partially transferred data is used to resume the transfer, but often the transfer begins anew. The intervals between the connections can be a few hours or a few days, sometimes even weeks. I do not have any control about the remote PC but I can politely ask the remote user to perform some changes in the Syncthing config, if necessary.

Now my question is - is there some way for me to tell Syncthing to always keep the partially transferred files and resume transfer? I am trying to transfer the files for several months now and it’s not fun anymore. :pensive:

Yep, set keepTemporariesH in Advanced -> Options. By default it’s 24 hours, after which temporary / failed to transfer files are deleted.

1 Like

Oh, thank you very much! Will test, much appreciated! I assume it’s enough if I set this option on my PC (the target of the transfer)? Or do I have to set it on the remote PC (the source) as well?

1 Like

On the destination, where the temp files are created while attempting to download data.

1 Like

Thank you!

1 Like

Are there any circumstances under which this does not work? I have set the limit to 1000 (hours) on both source and destination, however, it does not always seem to work as expected. I did not monitor the transferred amounts exactly (since I trusted the setting), but I have a very strong feeling that yesterday one file resumed from 600 MB and was transferred to about 1.5 GB (out of 2.6 GB) but today it continues from 1.1 GB for some reason. Any logs I could check? Any ideas why this might be happening?

Thank you.

The resuming works by hashing the blocks in the temp file and not transferring the ones that are already correct. Given this is block level stuff you’ll need to dig deep into the trace options to get logging, and then it’ll be thousands of lines per transferred file and some work to correlate.

I can’t see the temporaries age limit having any effect on this, that just controls whether the file exists at all or not.

I see. I’ll keep watching the numbers then. How large are the blocks, please?

128KiB to 16MiB in powers of two, depending on the file size, aiming to have 1000-2000 blocks per file.

Thanks. Is there perhaps some kind of large cache that might not have gotten flushed?

The temp files in question are the cache, there is nothing else.

1 Like

And again resuming from 1.1 GB instead of 1.58 GB (which I wrote down last time so I remember). Is there perhaps some upper limit to the setting of the hours that the temporaries are kept? E.g. I specified 1000 hours but perhaps 48 is the max value and now it uses again 24 hrs as the default?

It would start from 0 if it didn’t find the temporary file, the fact it starts from non-zero means it did find it. It probably means the data changed and it salvaged as much as it could.

That would make sense if it made sense. The files had no reason to be changed, neither the source files at the source nor the temporary blocks at the destination. I am at my wits’ end.

I don’t think there is an easy way to debug this.

It logs how many blocks it reused as it starts the download, which I guess would grow every time it starts a download, but if it doesn’t, or decreases, it won’t tell you why.

You can probably roll up your sleeves, add some debug logging to your satisfaction and roll your own build.

I don’t have any more advice sadly.

Thank you very much for the help nevertheless.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.