Syncthing: Option for trashcan versioning to affect only deleted files, enable by default

[calmh]

I just read a sad story of someone losing all their files due to misunderstanding the nature of Syncthing and what would happen on side B when files are deleted on side A. It's not the first such story I've seen. We can say that this is a user misunderstanding and they should be more careful, and there is truth in that. Yet, we can fairly easily prevent some anguish here.

We have requests for versioning to be enabled by default with some frequency (#368 from five years ago and onwards). There are reasons we haven't done that, which is mostly about expectations from more understanding users, and avoiding to fill users' disks unnecessarily.

I propose that we:

• Improve the trashcan versioner with an option to only store deleted files (not modifications).
• Enable the trashcan versioner by default for new folders with the following options:
  
  
  
  • Only store deleted files
  
  
  • Keep versions for 7 days
  
  

Disasters are thus averted while avoiding to store twice the data for any given folder under normal usage. Users can complain that free space is not reclaimed when deleting, in which case we can point to this setting and it can get disabled.

[GermanCoding]

A thing that comes to my mind is if it would be useful to force the user to have a glance at the versioning settings, when adding a new folder. No excessive things like an additional popup, just a layout that makes you see the current versioning setting immediatly when adding a new folder.

This could benefit the following:

• New users are - more or less - automatically introduced to versioning
• For existing users, any change of default values in versioning (as proposed here) would be more visible, so there's less surprise

This would probably require at least some amount of UI redesign, since the current tab-based layout easily allows missing everything but the 'General' tab. On the other hand a redesign may not be feasible right now.

[Catfriend1]

I think this is a very good idea, even with a short delay of holding deleted files in the trahscan so assuming users accidentally doing deletion wrong would notice it very quickly. I'm already trying this since some weeks ago with users of Syncthing-Fork and await their feedback if it helps or hurts.

[AudriusButkevicius]

I think if you don't understand what you are doing, stay away from it.

Forcing everyone to have to go into settings, and disable a thing, just because there was a person who hastily made decisions without reading the labels is a punishment for 99% of users, not the saviour for 1%.

You can't protect people from lack of education.

[calmh]

Having versioning be more visible wouldn't hurt, but I don't think it's the whole truth. This is about assumptions and expectations the user might make. Any user grown up on Windows or Mac is going to expect deleted files to go into some sort of trash thing that requires emptying, thus giving them a chance to rectify their mistake. Syncthing subverts that expectation by making deletes instantly permanent across all devices.

It's also about damage levels. If we accept the 1%/99% division for now (which I'm not so sure about), that's 99% of users suffering a small, temporary loss of free space or having to toggle a setting, vs the 1% who lose something precious and irreplacable. It's very asymmetric and optimizing for the 1% seems valid. Especially given that the 99% are apparently good at research and avoiding hasty decisions, so they'll probably check the versioning tab and disable it if they don't want it, right?

I mean, I get it, I've argued for years that we shouldn't do this because it's unnecessary. But we're a bit more mainstream now and will by necessity gain some users who are not techies. Installing airbags and seat belt reminders will annoy some, but save others... I think the situation has changed so that the responsible things is to have those things by default and let the people who care do their own thing.

[AudriusButkevicius]

This badly breaks my "is it a sensible default" spider sense.

The problem here is not that the "people expect trash can like semantics", because I am pretty sure very few or nobody expect that as an out of the box.

The problem here is the fact that there is very little explanation or guidance on how syncthing works or what it does.

A first folder wizard is probably what we need, with a checkbox (based on folder type) saying "My files will be deleted from every device, I'm game with that"

[Ferroin]

Just my two-cents as a user:

• I think versioning really should be more clearly visible. I'm not sure what the best way to do that is, but I suspect that will actively avoid the issue to some degree.
• If, once versioning is more visible, people are still having this issue frequently, then we should look at enabling versioning by default.
• Regardless of what's decided for the defaults, I think having an option to have trash-can versioning only save deleted copies is a good feature.
• If we're going to go with the trash/recycle bin argument as a basis for expectations, why don't we just integrate with that by default if the environment supports it? Make it a different versioning option, (with an option to only 'version' deleted files), punt to the OS for handling, and make _that_ the default. Then the user can find the files exactly where they are probably expecting them to be if they got accidentally deleted. Support on Linux/BSD is reasonably easy (see the FD.O tash spec for info), though I'm not sure how much work it would be on Windows/macOS.

[calmh]

Support for system trash is surprisingly difficult to do cleanly for the relevant systems, I tried a couple of years back.

The problem here is not that the "people expect trash can like semantics", because I am pretty sure very few or nobody expect that as an out of the box.

Is there some basis for this assumption? I think that all of the cloud based sync services provide a (cloud based) undelete window. The system itself does it for files deleted by the user there. The only exception here is the Unix CLI and even then, even rsync requires a fairly obvious --delete to even do deletes at all.

[AudriusButkevicius]

I think we have to decide what are we building here.

There are no safety nets in unison, no safety nets in btsync, because these tools work on the local storage which might be precious, and storing these copies can break normal operation, because we unexpectedly filled the disk, and suddenly some important data is not synced and potentially lost, not because of users fault of not reading the manual, but because of our surprising defaults.

I think that's a scenario which is going to be more likely, and people will bitch more often about this than people who went full yolo and did not realise delete means delete.

Also, if recycle bins are such a defacto thing that is just given (exists) everywhere, surely the user can recover the files from the recycle bin where he initiated the delete? Why do we have to do it a second time for them, in a distributed way across all devices, consuming space everywhere by default?

All the cloud offerings I checked do have a recycle bin, but thats a separate story, as storage is infinite there and it's something that providers can afford.

[i0x915]

I think trying to integrate with the OS trash bin is going to be a disaster, every environment/UI has a different implementation.
I've been using Debian with xfce for almost. 10 years and I have no idea where trash bin is hidden. As a Linux user that spends most of the time in a terminal having to find where environment hides trash files would be a a nightmare, I would much rather keep the trash bin versioning the way it is now.
As for the default trash bin versioning idea, it's not a bad idea, as you can see from real life examples, there are Infact people which need this feature enabled by default.

[AudriusButkevicius]

I am not convinced they do, as per my comment above. They should check their OS trashbin, wherever that is, and if they are not on a consumer OS (aka linux et al), expecting stuff to go to the bin was wrong in the first place.

[i0x71]

I disagree with the assumption that expecting stuff to go in trash bin is wrong, it is nice to have in a case where you are not manually managing your files as it is the case with syncthing. If one day my local syncthing client decides that some of my files should be deleted, id rather have them go to the trash bin than disappear completely.

There is a big difference with a user manually copying and deleting files vs when software does this for you, especially when you have to deal with conflicts and multiple peers and then automatically make a decision.

[Hob111]

Also, if recycle bins are such a defacto thing that is just given (exists) everywhere, surely the user can recover the files from the recycle bin where he initiated the delete? Why do we have to do it a second time for them, in a distributed way across all devices, consuming space everywhere by default?

A good point and appropriate for users of Windows and most GUIs on Linux. However, I'm not aware of a universal recycle bin on Android, the presence or absence of one seems to depend on the app used to delete the files (someone please correct me if I'm wrong).
The arguments against consuming space with an automatic recycle bin are strong but the original suggestion was to:

• Only store deleted files
• Keep versions for 7 days

which shouldn't be too space consuming although it could be critical on a system where space is at a premium. It might be apparent that I'm fairly ambivalent, there is no substitute for RTFM but how do you persuade a new user to do just that?

Maybe the clue to its operation is in the name of the application, Syncthing?

[tuarrep]

My 2 cents trying to be constructive.

There is two aspects in the original proposal:

• Improve the trashcan versioner with an option to only store deleted files (not modifications).
• Enable the trash can by default

As some of you I'm not a real fan of enabling the trash can by default. For me Syncthing is made to sync things and have a consistent replication over devices, not to manage files like a _cloud_. User must choose the right tool for his needs.

BTW, as a user, I found the proposed trashcan versioner modification really interesting. _Purposely_ turning it on can make sense for some users. I've two use cases in mind.

First, on Windows, antiviruses are sometimes aggressive and put lots of files in quarantine just _because_.
I'm using Linux but sharing some folders with windows devices and sometimes bunch of files disappear from my folders. Having a place to rescue them without exploring antivirus options and menus will be great.

Secondly, I use Syncthing to sync sound databases between servers (for radio broadcasting). Sometimes, we run batch operations to populate, convert or clean them. In these processes lots of files are deleted (and created).
Currently we have a snapshot of our testing database (about 27.000 files and over 500GB) duplicated to restore deleted files (purposely or not) during scripts development.
Letting Syncthing keep a copy of deleted files for us will make the restoration faster by restoring only deleted files, let us easily if process goes well by counting / listing deleted files and avoid us to maintain the snapshot in sync.

About the sad story which originated this issue, I think the smarter and easier thing to do is to alert user on how Syncthing is designed and works on the first GUI boot up (a sort of onboarding). Two points seems to be very important:

• Syncthing keeps folders in sync across devices whether files are added, modified or deleted;
• Syncthing offers some versioning options [link to the docs].

For me, this leads to 3 different and almost independent points to discuss (and potentially 3 distinct PR):

• Does the trashcan versioner need an option to only keep deleted files (not modified ones);
• Does a onboarding screen can be useful to educate user about Syncthing goals;
• Does we need to enforce defaults for versioning.

IMO, the two first need more attention and feedbacks to be constructive.

This is just my opinion as a feedback, I'll be happy to discuss it with you.

[MollyBe]

I appreciate that you're reconsidering this. I've only been using Syncthing for the last few hours. I wrongly assumed how syncthing would behave and was surprised to find my files deleted. I was very grateful to find an ignore delete option though!

I think the placement of the ignore delete option could be improved, I probably would of found it sooner if if Action > Advanced > Advanced Configuration Folder Settings where included in the main folder configuration page 'Edit Folder'/'Add Folder".

Data preservation should be a top consideration when defining default settings, troubleshooting why your files haven't been deleted is so much better than the alternative.

I would consider this the main argument expressed against this:

Forcing everyone to have to go into settings, and disable a thing, just because there was a person who hastily made decisions without reading the labels is a punishment for 99% of users, not the saviour for 1%.

This is easily resolved by allowing the user to set custom default settings - perhaps also being able to load an existing configuration (sans folder id.) I hope this is already possible, or i can hack it, because I plan to enable trash can versioning, ignore delete by default, some ignore filters and half a dozen other settings I'd rather be my default.

[rjpruitt16]

I would like to work on this. I know I don't have to ask for permission, but there seems to be an unresolved debate. To confirm what is desired, the feature request made by @calmh in the beginning is still the objective.

[calmh]

I think it's only "enable by default" which is contentious, and that's a trivial detail. Avoid that and I foresee no problems with a PR.