I have been running a Syncthing setup now for two weeks which has proved to be more than adequate for my needs. I just sync a Download folder between all my devices which is 1 phone, 1 tablet a desktop, and a laptop. Whenever I download on any of these devices, the item appears on all of the others, including the deletions of items. Great…
But… I have my own yunohost server and I have installed Syncthing on that, and again I have set it up so that whatever I download on my computers and mobile devices the item appears in a Download folder on my Server.
The items on the server though I want to keep, forever just in case I delete an item on one of my devices I can then go back to my server and pick it up.
I have set the folder on all of the devices to Send & Receive but the server to Receive ONLY, as I’m thinking that I want the server to Receive Only the items but keep them when I delete on a remote device. (I bet that’s the bit I’m wrong on?)
It doesn’t work, items are still being deleted on the server’s RECEIVE ONLY download folder.
Clearly, I’m doing something wrong and I have trawled through the forum trying to see if I need versioning and which one, etc.
Can anyone give me a clue, please?
I want the remote devices’ Download folder to be synced, including deletions, (which it does and works well) but I want the server to keep the downloaded items even if they get deleted from one of the remote devices. (I can’t figure that one out because… I’m a dunce. Probably…)
Further, Syncthing have the feature Ignore Delete. However, this function is not welcomed, as it seems to be a quick-and-dirty feature, which the Syncthing team strongly advises against. It is basically something like “concealed”.
I think the feature should either be taken out or developed. I would support the latter, as you can see again and again that the users need it. This is another one of those cases.
Receive-only folder type means it will only receive changes from other devices, and will never announce changes happening locally to remote devices. Changes include deletions.
For what you want to achieve, you can either setup something else to create backups (e.g. do zfs snapshots) and/or enable versioning, to preserve items deleted on remotes: File Versioning — Syncthing documentation
Then you want versioning. Please don’t just dismiss not recommending it as “frowned upon”. It’s just that there are much better solutions to the problem you have than “ignore deletes”. Your initial statement about “accidentally deleted stuff” is a prime example of why one uses Syncthing’s versioning and periodic backups.
Edit:
What about invoking the wrath of the internet by installing a word-filter that throws all posts mentioning the option who’s name one doesn’t write into the moderation queue? (in case it isn’t clear to anyone: I am kidding - but really, don’t recommend it).
What Simon says. The option that shall not be mentioned will break your sync setup and cause anguish, anger, and hate. Trashcan versioning with infinite retention will keep your deleted files just as well, and not break anything.
Simon do you think that Staggered File Versioning would work? Seems ideal as you can have a kill time when items WILL get deleted thus keeping the number of items down and stop the server from filling up!
So for example the server is set to Recieve Only, Versioning: Staggered and set for 30 days say.
Staggered is useful for keeping multiple versions of files as they change over time, in a complex manner. Trashcan will instead just keep the latest version, optionally throwing it away after x days. As a bonus feature it also won’t mangle the files names, making restore easier.
@calmh thanks for coming in. I thought about Trash can versioning but wasn’t sure but you know what? I’ll give that a go, sounds like a plan. Thanks very much…
@calmh Thanks very much , just tested that and it’s perfect. Of course you have to remember that the .st folders are hidden. Yes my deleted items went into an new .stfolder and I’ve set it to empty in 2 days to see how it goes.
Thanks very much for your help and guiding and idiot!
How you manage and handle that feature is not correct, but that is my personal opinion. If it doesn’t work properly, cover it up or take it out for now. On the other hand, I personally consider an “Ignore Delete” to be as a standard option.
In order to simulate the feature in another way, the “misuse” of versioning is at most a help, but also not a solution. The problem is that deleted files and directories are mixed up with updated files. No one can handle that when it comes to larger volumes.
My suggestion would be to create a directory similar to versioning with “.stversions”, e.g. “.stIgnoreDelete” and to move all remote deleted directories and files into it. For me as a user, that would be a clean and acceptable solution, as this container would be separate from everything else. If a user then changes over and deactivates “Ignore Delete”, would the two main directories be in sync, or not?
It is covered up, we can’t remove it because it would be a breaking change that would start deleting data for existing folders where this was setup ages ago, and we’d have users with pitchforks at our door.
The option corrupts the database unrecoverably, so no, disabling it would not make things go back to normal, and you’d have to reset databases on both sides.
It seems to me that I was not properly understood. Versioning already exists. It is only about the suggestion to separate deleted elements if “Ignore Delete” is activated. This is not versioning, this is separation.
The question arise how that should work. Basically, only the database knows which elements come into question, doesn’t it?
I think there are template variables (or atleast there could be as per my initial thoughts on templating) you can use in the external versioner which tell you if its a modification or a deletion.
Edit:
It seems they are not there but I think it would be trivial to add.
