Trash should be default remove behavior

Feature
21

there already is one, with that it is easy :wink: batch.scripts/hybrids/jscript/deleteJS.bat at master Ā· npocmaka/batch.scripts Ā· GitHub (edit: well looks like JScript but can be used from a normal batch script^^)

22

Actually, even better, I propose:

  • Create a new versioning scheme called ā€œSystem Trashcanā€. This scheme simply moves files to the system trashcan, using the platform specific methods to make this integrate seamlessly.
  • Default to this versioning scheme on platforms where it exists - Mac OS X and Windows, at least initially.
  • Donā€™t touch the existing Trashcan scheme (except possibly renaming or clarifying the relation to the new scheme).
  • Donā€™t change the default on platforms that donā€™t have a System Trashcan scheme.

I bet a lot of people have found nice use cases for the existing Trashcan scheme on Windows and Mac and donā€™t want it removed. Thatā€™s usually what you find out when you remove a feature. :slight_smile:

5 Likes
23

Thanks for revisiting the idea of having a default trash. My suggestion is to keep things inside the Syncthing ā€œuniverseā€

  • enable trash can versioning by default
  • add little trash can icon for each folder in web gui if folder has files in .stversions
  • on click show list of files
  • make it possible to ā€œrestoreā€ (= download) these files via browser (this would allow to do things remotely as well)
  • show path of .stversions to user (for larger operations, AFAIK it is not possible to open a folder per click e.g. in Windows Explorer?)
24

I dont think you are right. Linux must be divided into ā€œserverā€ systems and desktop systems. The desktop systems offer with The FreeDesktop.org Trash specification a possibility for a trash can. The ā€œserverā€ systems should be treated with ā€œdelete directlyā€.

1 Like
25

Which systems follow this standard, and how do we tell?

26

This is on my ubuntu 15.10 machine:

`$ env | sort | grep ^XDG

XDG_CONFIG_DIRS=/etc/xdg/xdg-xubuntu:/usr/share/upstart/xdg:/etc/xdg:/etc/xdg XDG_CURRENT_DESKTOP=XFCE XDG_DATA_DIRS=/usr/share/xubuntu:/usr/share/xfce4:/usr/local/share/:/usr/share/:/usr/share XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/lars XDG_MENU_PREFIX=xfce- XDG_RUNTIME_DIR=/run/user/1000 XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0 XDG_SEAT=seat0 XDG_SESSION_DESKTOP=xubuntu XDG_SESSION_ID=c2 XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0 XDG_SESSION_TYPE=x11 XDG_VTNR=7`

27

knoppix.png799Ɨ203 23.6 KB

this is knoppix v6.7 from 2011

fedora.png733Ɨ216 22.9 KB

fedora 23

I currently dont know how to retrieve a list of distros.

28

Iā€™m not sure what youā€™re saying, though. Is any of these variables indicative of the fact that we should use a trash folder?

29

Sry, to few words too late in the evening.

XDG has a trash spec. And these environment variables indicate a XDG desktop session is running. So we only need the path to the trash. I just try to figure out on my local system.

30

I just thought about determining the strategy and would say skip that for linux and directly delete until user feedback ask for better support. I think it will be kind of flaky detection. Sry for the spam :expressionless:.

1 Like
31

This is really what I was getting at in my post earlier. While I love the standard trash on my desktop linux systems, checking for all of the implementations is not realistic for ST.

Letā€™s make delete the default behaviour on Linux and add an example of using trash-cli in the custom versioning doc.

32

Hereā€™s a question I posted in the PR, but for a wider audience:

We trash (ā€œversionā€, currently) files when theyā€™re overwritten and replaced as well as deleted.

Does it make sense to have something that claims to be the ā€œsystem standardā€ way of using a trashcan / recycle bin and have it put copies of files in the trash on every modification? Does anyone else do this?

If not, what we would implement here would be something entirely different from the ā€œusualā€ versioning schemes that we already have.

1 Like
33

Check send2trash python library, it already deals with all this linux env var madness, and works out if there is a trash can or not, and where it is.

34

Good point. This is different to the trash can versioning and isnā€™t a drop in replacement.

35

The thing is that that freedesktop ā€œspecificationā€ (yes, scare quotes because I think itā€™s fairly crap) assumes a desktop environment. The env var parsing thing isnā€™t too tricky - itā€™s basically just use $XDG_DATA_HOME/Trash or look for a top level trash. But the spec also says that $XDG_DATA_HOME defaults to ~/.local/share when unset. The python library you link seems to implement this.

For our purposes this means that if we are to follow the spec, we should always trash files to somewhere like ~/.local/share/Trash even when finding no environment variables at all set anywhere. This is what Iā€™m very subtly hinting at in

because as far as I understand we canā€™t and I have seen no indications that the freedesktop ā€œstandardā€ (yes there I go again) is wide spread enough that we should assume itā€™s in effect on all unixy systems.

At the very most I could possibly imagine doing the trash thing if and only if $XDG_DATA_HOME is setā€¦

2 Likes
36

I have my Syncthing clients set up to always save multiple backups for every file, so Iā€™m not in any danger here. But I strongly agree that supporting the system trash can, or some similar solution, is important. For every system.

Thereā€™s been a trash can in every Linux desktop environment Iā€™ve ever used, and Iā€™ve tinkered with a lot of them. I would not say that ā€œdelete a file and itā€™s gone foreverā€ is the expectation at all. Maybe in a headless system only running as a server ā€“ but still, having some way to un-delete enabled by default on all systems would be good. If testing to see whether the client computer actually has a Trash folder is too complicated, then at least put the files in the usual .stversions directory for some amount of time.

Thanks.

37

I bet a lot of people have found nice use cases for the existing Trashcan scheme on Windows and Mac and donā€™t want it removed. Thatā€™s usually what you find out when you remove a feature. :slight_smile:

Thatā€™s a really good idea!

(Relevant xkcd:

)

3 Likes
38

Are the .stversions folders replicated among machines?

I have setup simple file versioning on my largest server instance, and not on the others.

We use netatalk/OSX Finder, that means zilch network trash. So if a user on a satellite node deletes a file, it lands in .stversions on the large server. But if the deletion happens on the instance that runs the versioning config, then the file is gone.

In addition, having a remote trash can is kind of counter-intuitive (and impractical) when you want to just ā€œundoā€ your mistake.

Why not a visible directory, say Sync-Journal, synched automatically among peers, that would hold local files or remote pointers to files that were modified/deleted? And mandate at least 2 nodes with the same file versioning setting, in order to receive and store all deleted files, even when the OS doesnā€™t offer a trashcan facility?

Makes no sense? Just say so :wink:

39

.stversions is not shared among all nodes.

What you are suggesting could be implemented in a custom version scheme but I donā€™t think it fits into the scope of vanilla Syncthing. Happy to be corrected if one of the main devs disagree.

You have to consider how many conflicts can be caused by a couple of changes on multiple clients and how this conflict files could conflict with each other if they were synced.

40

Have a look at @lkwg82 post. It seems that $XDG_DATA_HOME isnā€™t set. But $XDG_CURRENT_DESKTOP in ["GNOME", "LXDE", ...] should work for most users :slight_smile:

1 Like