Leftover .syncthing.tmp files


(Clemens) #1

I use Syncthing to distribute data from a central server to remote devices every night. For this I setup a new folder configuration and after the sync is reported to be complete to all devices I remove the folder from the config files.

I now noticed that on each remote device are about 50 syncthing tmp files with the name: .syncthing.fileName.tmp left over. I would like to leave the folder in a clean state.

Is there a cleaner way to remove the folder, which removes tmp files or should I do it by hand?


(Simon) #2

Temporary files are removed after 24h.
However leftover syncthing.*.tmp files are a sign of incomplete or aborted sync progress, so you should probably investigate that (possible question: are the non-temporary files really equivalent to the source and are the temp files also equivalent or different?).


(Clemens) #3

Do I guess correctly, that they are not removed when the folder is not synced anymore?

I will run a thorough check, but as far as I have seen those are temporary copies of files that were removed on the master (probably during the downloading process) and therefore should not be there anymore.


(Simon) #4

They are removed, if they are below an “active” folder root (active as in there is a Syncthing instance running and scanning this dir).

I didn’t check, but that sounds like a probable explanation. I.e. the temp file for the aborted item will stay around, and the subsequent deletion won’t be pulled in, because the item was never successfully pulled (i.e. it doesn’t exist, so pulling a deletion is a noop). And even if the deletion was pulled, I am not sure whether we do also check if there is a temp file and remove that as well (sounds like something we should do).


(Audrius Butkevicius) #5

The scan deletes old temp files, not the pull.


(Simon) #6

I know, but wouldn’t it makes sense if a pull deletion would do so too, e.g. in such a scenario:

  1. Start pulling a file.
  2. Pulling is aborted due to request failing due to file being deleted on the remote.
  3. Next pulling iteration deletes the previously aborted file.

Current result: Temporary file still around.

Possibly better result: Temporary file also gets removed.


(Clemens) #7

I have the filewatcher enabled on all devices, could that mean that the scan which would trigger the delete is never triggered?

As far as I understand it the folder should be triggered, because the tmp file is changing in there, but I am not sure if you filter those triggers out.


(Clemens) #8

I have to make an correction on what i said before.

The files exist on both sides and are exactly identical. I checked all the files if they exist or if they are deleted on both sides and they actually are all existing on both the master as well as the slave.

I thought it might be deletions, because near the end of the sync are almost only deletions.


(Audrius Butkevicius) #9

Even if the watcher is enabled, periodic scan still happens every hour.


(Clemens) #10

I now wrote a script to check all files on all devices and I have between 50 and 450 leftover syncthing tmp files after syncing 300 000 files. In all of these cases the file was synced successfully and is identical to the original file.

I guess these are only leftovers which I can just delete with my script.

I am not sure if it is reasonable for you to do a cleanup once the folder is unsynced. I know my case of creating folders every day is not your usual usecase.

Thanks for your help.


(Audrius Butkevicius) #11

They do get cleaned up after 24 hours as I said. You can set the retention to 0 hours, and force a scan before you remove the folder to clean them up.

Or just find . -name pattern -delete


(Clemens) #12

I will probably just clean them up with find like you said.

I checked the results again today and this time I found both: Files that were deleted on both sides and files that exist on both sides. This means that the temporary files are just left over from interrupted sync processes.


(Audrius Butkevicius) #13

Yes they are, as explained above, yet they get removed after 24hrs…


(Clemens) #14

Since I am removing the folder before the 24h are over, they will not be removed. And even if they were I only need the folder for about 14h after the sync and it is getting removed soon after.


Not propagated deletions