Well, I guess I am another one who (loves Syncthing, but …) wrongly understood the documented versioning capabilities BEFORE to decide to go for it, I read it there in the Syncthing doc :
Syncthing supports archiving the old version of a file when it is deleted or replaced with a newer version from the cluster.
Maybe one should amend the wording with
when it is deleted on a remote device
The issue, however, is that such wording would make Sincthing much less attractive compared to other modern options (none of us want that, do we).
To be consistent towards the users who did (or will) read that doc, at least a non-default, non-corruptive, elegant-enough solution would be fantastic.
I’m a techy kind of user who supports the need to keep the solution as simple, performing and straight-forward, for maintainers and users, as possible. So granted that redeveloping a versioning OS feature is not the goal here.
Instead, if there were an elegant way to allow remote versions to be synchronized back to the deleting device, I believe that the feature benefit would be worth the extra CPU+bandwitdth cost (at the condition that sync loops are prevented of course).
Such a solution might already work, but could be at the expense of tricky settings like ignore rules (have fought with them already, and lost, and I’m not the only one) that must cope with:
- possibly different versioning strategies on different devices for the same folder (I was surprised to see that this is allowed, might prove useful though I recognize)
- the need to have a visible, or not, “Version History” (or, …you name it) folder, on required devices (here too, I thought that would be an enforced consistent setting across the cluster, seems not)
- and more, possibly …
So: what would be great (if confirmed as required) is an option in the UI and/or protocol to strengthen the consistency of required folder settings (versioning folder name, ignore rules, versioning strategies, maybe) in a cluster for this locally available versioning purpose.
And hopefully that might be quicker for a developer to think it over and implement it than for me (us) to write and rewrite this plea (and the same developers to decrypt them.).
Hope this is useful.
And ultimately effective 