Copying old syncthing config led to data loss

Thank you for syncthing!!!

tl;dr use “Receive Only” when that’s what you intend to do; have a backup system; Please advise re: file recovery software?

Today, before reinstalling GNU/Linux on one of my machines, I copied the ~/.config/syncthing folder to a thumb drive with the intention of copying it back into place in the new installation.

When I did this on a different device a few months ago, the sync directory on the device with the new installation immediately began populating with files from other devices in the swarm. This time, the opposite happened: all of the files in the shared directory were deleted on all three devices in the swarm. None of the devices had enabled “File Versioning”.

A warning to other users: Be sure to mark the empty directory as “Receive Only” before syncing. Also, be sure to always make backups.

Do you have any thoughts on what may have happened differently this time around?

When I realized what had happened, I shutdown one of the remote devices in hopes of later attempting to recover the files. Would you share some advice about file recovery in this case (tens of Gb lost)?

Backing up and restoring only the config should be safe, i.e. Syncthing should just download the files from other devices without deleting anything. However, judging from the explanation above, it seems that you have backed up and restored everything from the Syncthing’s home folder, which includes the database. With the database restored and the folders empty, Syncthing will indeed consider the files deleted and push those deletions to other devices.

If you’ve got no external backup (and haven’t used any file versioning strategy within Syncthing), then the only way right now is probably to use some kind of file recovery software. Please read up on that if you’ve got no experience, as there are some essential steps to take, e.g. disconnect the drive, move it to another computer, and only then try to recover the files onto yet another drive, without writing anything to the original one.

Which, of course, is not the case right after copying the configuration directory. There you will have the send-receive folder type already configured and probably notice only after starting Syncthing and looking at its GUI, when already too late.

I think that the trouble could be avoided if Syncthing didn’t use a path for its configuration and state that users rightfully expect to freely share / copy among devices.

Yes, that’s correct. Thank you for the explanation!

Thank you!! I will proceed with care.

Yes. This is indeed what happened. (I would update the topic post, but I don’t see a button to do so.)

Perhaps Syncthing could use XDG_CACHE_HOME for the db? As an aside, would it make sense to use XDG_STATE_HOME for keys?

Database is not cache, meaning that you can’t just delete and regenerate it with no consequences, e.g. if you do that while synchronisation is still in progress, it will likely lead to conflicted copies and possibly “undeleted” files. Additionally, some advanced options like the infamous ignoreDelete also rely on the database to know which files have been deleted, etc.

Thank you for explaining.

How do you think a change like this would look?

See Default config (state) dir on Unixes should be ~/.local/state/syncthing ($XDG_STATE_HOME/syncthing) · Issue #9178 · syncthing/syncthing · GitHub, where incidentally we had that exact same discussion today. The outcome was that $XDG_STATE_HOME is the correct place and should be used for everything instead of $XDG_CONFIG_HOME. Just that someone needs to implement it, so don’t hold your breath… :wink:

1 Like

Thank you!!

This should be better handled in the next release candidate: lib/locations: Change default config/data location to new XDG recommendation (fixes #9178, fixes #9179) by calmh · Pull Request #9180 · syncthing/syncthing · GitHub

Note that you will need to manually move stuff into the new default location though. It will be fine when setting up from scratch.

1 Like

Thank you!! That was fast! had I been holding my breath, I’d be okay :slight_smile:

Well at least now don’t hold it until the change lands in a stable release, which is more than a month out… :wink:

And Kudos go to @calmh for fixing it quickly, I was just the one advocating for the Right Thing.

Thank you @calmh!!!

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