I still stand the point that it’s not very thought through (a hidden dir? Why?), and that blindly implementing it is annoying. It shouldn’t be a universal standard for all systems, as it’s only relevant if you use a file manager which can then use that dir as Trash dir - which I don’t. That could be tested by only allowing filemanagers to create the dir, and if it doesn’t exist, discard the data. That’s probably how some programs work, as only Prismlauncher has created the dir.
Hab tagelang hass geschoben weil der Schmutz mir massiv Speicherplatz geklaut hat. Muss halt zu dev/null symlinken und prüfe regelmäßig global ob es ein neues davon gibt.
you should do this with every one of these cases. btw, where does .Trash-1000 actually come from?
Freedesktop.org’s trash specification. It’s where files moved to trash go before being deleted when it’s emptied. The 1000 is the user id.
.Trash-999 was already taken by a metal band.
I had a long and frustrating conflict with this, on this post.
As @[email protected] (An dem Punkt könnten wir auch einfach Deutsch labern) noted, it’s a freedesktop.org specification.
I still stand the point that it’s not very thought through (a hidden dir? Why?), and that blindly implementing it is annoying. It shouldn’t be a universal standard for all systems, as it’s only relevant if you use a file manager which can then use that dir as Trash dir - which I don’t. That could be tested by only allowing filemanagers to create the dir, and if it doesn’t exist, discard the data. That’s probably how some programs work, as only Prismlauncher has created the dir.
Workaround: ln -s .Trash-1000 /dev/null
I agree. It somehow seems very unfinished, and it annoyed me more than I’d like
Hab tagelang hass geschoben weil der Schmutz mir massiv Speicherplatz geklaut hat. Muss halt zu dev/null symlinken und prüfe regelmäßig global ob es ein neues davon gibt.
The land of the penguins