Feature Request: Add some sort of trash can for cases when files are deleted

Hi!

I just started to use syncthing to sync files from mobile phone to my home server. And lost my data on mobile phone in my case. My configuration included “Downloads” folder of “send and recieve” type. When synced “Downloads” folder was deleted on server (it was my fault, another story), I created empty folder and file “.syncthing” inside it. After that Syncthing deleted all files on mobile phone in “Downloads” folder. And data was lost forever. So, it would be nice to add case in HOWTO. What to do in such cases when you have lost your folder on one of device? Google found nothing for my query. Another nice feature would be to have some sort of Trash Can for delete operations. So, I can review and accept files/folder remove.

And Web UI is nice: simple and informative.

Thanks

1 Like

There is something similar in the versioning settings.

Also, when something bad happens, trying to brute-force a solution without understanding what the implication is a terrible idea. It’s not hard to ask on the forum.

So, may be turn on versioning by default? For example, set versions count to 1 for delete operations…

That would be unexpected to the user when deleting files actually does not reclaim space. Users are given the option to configure this themselves upon adding the folder.

The problem here is not the defaults, but the fact that you went on your own and tried home remedy to fix something. You could have gone and changed the settings before attempting that, or could have just consulted on the forum.

You are right. But I prefer when any solution is safe by design. Because there can be different situations: children are crying, you just want to sleep, or may be it is time to save the entire world… but you have to understand how Syncthing is working, to not make situation even worse…

The solution is safe by design. If you delete the folder, it does not delete it on the other side, it returns an error.

However, it is not safe when you start applying home remedy, doing random things like creating syncthing’s internal files without understanding what purpose they serve.

2 Likes

Users know how trash can is working (same on Windows and on macos). So, trash can will be simple and known solution.

And we are not talking about my person and mistakes I have made… I am just trying to help you make Syncthing better.

The options are there, the users are free to do whatever they think is best, however I disagree that this is a good default, as it fails my “least surprises” test. I would be surprised if deletes did not reclaim space.

2 Likes

This is a somewhat thorny issue and people have different opinions and expectations. We try to err towards the safer alternative, but so far we’ve decided that in a sync solution deletes should be deletes by default.

The one exception to this that I think we should implement is that deletes should go to the system trashcan on systems that have such (Windows, Mac). This is different from the versioner though, as that one also saves modifies files which is not the OS default otherwise.

3 Likes

This will be hell to implement on Linux where every other DE seems to have its own trashcan system.

Yeah, so Linux doesn’t have a concept of a system trashcan in my opinion.

But if we did have an implementation of it otherwise, I could see a simple "mv trashcan" where you can just say “the trashcan for this folder lives in ~/.Trash” or whatever. Might be the 90% solution.

1 Like

There is a spec which is followed by at least GNOME Files, KDE Dolphin (two of the most popular Linux DE) and xfce Thunar.

So it would be a matter of moving the file to $XDG_DATA_HOME/Trash/files and creating a .trashinfo file in $XDG_DATA_HOME/Trash/info like this:

[Trash Info]
Path=/home/foobar/foobar.txt
DeletionDate=2019-10-17T20:58:00

I think if this concept ever becomes a feature it would be great to have it default to “on”, but with a (checked by default) checkbox in the folder settings to turn it off.

Entirely personal opinion is that this should be one of the things implemented (or at least activated) by wrappers. There’s also practical aspects (wrappers can be targeted at a specific platform), but mainly I just want Syncthing to sync (just like rm/rsync/scp/…) - nothing more (unless I tell it to). I hardly ever use file managers and it annoys me every time when I find that some program put stuff in a hidden trash folder somewhere - I do backups. And I can imagine a few people using Syncthing on server-like systems would agree with that. Essentially I’d like Syncthing alone/by default to follow unix philosophy (do one thing well) and require user interaction/wrappers to put candy on top for integration in systems/DE/… or other extended functionality.

3 Likes

Makes sense. Do we already have API hooks that would allow wrappers to do this?

I don’t think so. That would probably be doable with the proposed pre-sync hooks (there’s a ticket for that somewhere). Anyway my comments were merely a high-level opinion, not a proposal. I’d also totally understand if having a little bit safer defaults is valued more than my desire to have a sync solution that goes out of my way by default :slight_smile:

I think that a feature such as using the OS trash can should be implemented everywhere or nowhere - else one might be very surprised to find out their files were deleted on their Linux machine without being moved to a trash can, when they’re used to that behaviour on their Windows and Mac systems. Ergo, since Linux trash can is hit and miss, not implement it at all via the OS-exposed concept.

That’s the thing with defaults, they will always surprise someone. I would be very surprised indeed if something started using some sort of trashcan thing on Linux, where I have never (during 25 years of usage) seen a trashcan. I would be very unsurprised though to see trashed files hang around in the trashcan on my Mac. :man_shrugging:

What about renamed files? AFAIK Syncthing sees them as a new file and a deleted file whose blocks happen to be reused locally. So would the deletion part trigger an effective copy into the trash can (renamed file plus trashed file)?

So possibly a smarter rename handling is even prerequisite to adding trash can functionality without wasting space?