Toggle versioning renamed files & folders

Feature
1

It would be great if there was an option to choose if renamed files / folders do or do not get versioned. However, deleted files would still be versioned.

Currently, renaming a single folder will put a duplicate of that folder and all of its contents in other user’s .stversions folder. This can rapidly eat up storage space if that folder has hundreds of gigs or terabytes of data.

As I understand it, Syncthing’s philosophy is to assume that users won’t notify each other when they rename a file / folder, and so if other users don’t find a file / folder under its old name, they would believe it was deleted (not renamed) and expect to see it in the .stversions folder.

This makes sense as a default configuration as it’s the safest option, but there are also downsides to not being able to configure this. First, lots of potentially unnecessary duplicate data. Second, using Syncthing’s philosophy, if other users genuinely believe a renamed folder has actually been deleted, perhaps by mistake, they may very likely restore that versioned folder back into the share under the old name, causing duplicate data that will now be synced to all other users. At which point, you’re still having to notify other users anyways that you renamed a file / folder so they don’t restore data unnecessarily and know where to find the new one.

If there’s a way to ignore renames when versioning in a future release, it would be greatly appreciated!

1 Like
2

There is really no distinction in syncthing between rename and delete+create, so we cant easily and reliably detect this and act on (the filesystem doesn’t tell us it’s a rename either). There are some “approximations” but as far as some users reported, they don’t always work. I’m not against the feature, but I suspect it would be a feature that only works sometimes and causing more questions and support load than simply not being there.

I’m also not sure I agree with your analysis on the philosophy, if other party decided to restore versions to what he thinks “recover lost data”, I think the mechanism is working as intended, regardless that it’s duplicate data, mostly due to the parties are not talking to each other.

The best I can recommend is either having a more aggressive cleanup policy, or implement a custom versioner that knows how to deduplicate things.

3

Okay, I see the problem more clearly now. Thanks for the clarification. It seems like it’s not something Syncthing could realistically implement with the current way the file system communicates.

Hopefully it’s something I can address with external versioning.

Thanks for your insights!