Is file manager "Send to trash" more permissive than "rm"?
 

Hi,

There is a useful directory test I don't want to be able to delete as a simple user because as it is in my ~/Downloads directory I could decide to swipe all in there regularly and swipe it along too... (NB: move test elsewhere is not conceivable here)

The easiest way I found to achieve that is to create a .protected file inside ~/Downloads/test whith the immutable flag (chattr +i).
So I'm still able to create files in it, modify or delete them but I won't be able to delete the directory itself.

rm -rf ~/Downloads/test is not allowed, great, but I can still send ~/Downloads/test to trash via my GUI file manager (Thunar). I can even empty the trash afterwards...
Why? How to prevent deletion by GUI as well please?

Thanks in advance :)

Should be able to do that by setting its attribute, or chmod it.

man chmod
man attrib

Maybe but so far I didn't manage to do it (event with ACL). Any hint?

Under Linux?

I don't use the so-called Trash can (part of gvfs afair?).
To understand why that doesn't work as expected, you should research that, and not the core utilities that do work as expected.

You can't easily prevent deletion by the GUI file manager - unless you want to make Downloads read only - which would be a strange thing to do.

Typically, deleting a file or directory by a GUI just moves it to ~/.local/share/Trash/. If you delete that directory, it gets automatically recreated.
Moving a directory is fast because it doesn't need to look at the contents.

BTW I have a Desktop directory in ~/ I wonder what would happen to my desktop if I deleted it in my GUI?
Decided not to test it.:rolleyes:

That immutable ".protected" file does not prevent renaming the directory, and that's basically all that hapens when a directory is moved to Trash.

I watched someone delete Windows once while it was running, just to see what it would do. .. it was exciting ... :D

But on my other than home trash bins get messed up some how, I don't really pay that much attention to it. because when I remove something I want it deleted, not put out of sight only to have to empty the trash again to finally delete it.

there is However a app called trash-cli that you can use. Variety uses it to delete files.
Wait I reread it, prevent deleting files ... that is a bit redundant. deleting, or not deleting files falls under file management, and it is the responsibility of the user to take charge of what gets deleted or not. backups help recover from human error.

make ownership of dir roots and change permissions so the user can manipulate files within same said directory. even if it is in your own home dir?

testing that theory right now.

that does not work because user is part owner in its own home dir.

I don't have aptsearch - but gives the same output.

trash-cli seems a bit tedious to use, although I suppose it could have a use inside a script.

.bashrc
sudoers for sudo is set to NOPASSWD:ALL
it takes the tediousness out of it. :D

Well done! This explains the first stage of the behavior. Immutable files can still me moved indeed.
However, it doesn't explain why I can empty the trash afterwards!

Oh you're totally right about renaming that is still possible. I wrote that mistake because I had tested chattr +i on the directory itself beforehand (but the result isn't what I want because I can't create or delete files inside afterwards). I've just edited my OP, thanks :)
But why do you say that moving to trash rename the directory?

Renaming is done by the mv command.
It just moves the directory entry somewhere else.
Appears to operate like a delete and create. :)

So a mv from one path to the same path simply appears to rename the file or directory.

^ Yes, I'm ok with that but that's the path that is "renamed"/changed, not the filename or directoryname itself ;)

You don't actually empty the trash. The protected file still exists in a directory under ~/.local/share/Trash/expunged -- pretty deeply hidden, but still there and just not retrievable via the GUI.
Moving anything to trash just changes whatever directory link points to that object. If you have something in your home directory such as /home/you/abcd and move it to trash, then a link to abcd is created in /home/you/.local/share/Trash/files and the link to abcd in /home/you is deleted. It doesn't matter whether abcd is a file, directory, socket, or whatever. If abcd is a directory, then whatever was contained within it will now appear under /home/you/.local/share/Trash/files/abcd . If abcd itself is immutable, you can't do that because the process of creating and then deleting a link requires changing the link count in its inode, and the "immutable" flag blocks that. But when a directory (not itself immutable) is moved, anything within it just "comes along for the ride" without needing any change to its own inode.

I tried creating a file in my home directory and arranged for it to be owned by root, with root read-only permissions.
My user GUI happily moved the file to Trash.
All quite understandable, so far.

Still as user, I asked the GUI to empty the Trash - which it did.
Assuming the File Manager doesn't have a SETUID component component, how did I gain the necessary write permission to remove that file?
(It didn't get put in ~/.local/share/Trash/expunged)

Testing with Debian 10, KDE 5.14.5, Dolphin 18.08.0


Creating a file like this...
The file can be moved to Trash, and Trash can be emptied.
However, the file can also be removed with rm.
Neither "sudo locate testing-deleting-files" nor "sudo locate expunged" returned any results (after an updatedb of course).


Creating a file like this...
The file cannot be moved to Trash, (nor can be it be removed with rm).


Creating a file inside a directory like this...
I can move the directory to Trash, but cannot empty Trash.