Why is it a lot faster to call rm on a directory than deleting a folder from the GUI (Linux) over SSH

Question

Out of curiosity, why is it a lot faster to delete a folder / folders in Linux (I'm using Ubuntu) over SSH by calling rm -rf somefolder than deleting the folder from the GUI (right-click then "Move to Trash)? The folders I'm deleting contain about 100 image files each, and it probably takes a couple minutes to delete the folders in the GUI whereas rm -rf runs instantaneously. Do the two actions actually achieve the same effect, or does rm -rf only remove the link to the files?

Answer 1

You didn't specify this in your question, but I suspect that your GUI is based on some kind of filesystem-over-ssh feature. That might be slowing things down as every low-level operation (open directory, read directory, unlink file1, unlink file2, ... close directory) is passed over the ssh channel as a separate command.

When you run rm -rf x from the shell prompt on the remote machine, the only thing being passed over the network are the keystrokes you used to enter rm -rf x and Enter. (Those do get bloated up somewhat by the network protocol headers, but they're still reasonably small.) The low-level operations are conducted by the rm program on the remote end, talking directly to the kernel on the remote end, so naturally it's faster.

ssh was designed to provide a shell interface (the name should be a clue). The other stuff that's been bolted onto it is less efficient.

It would be possible for a filemanager-over-ssh implementation to optimize the recursive removal case and simply ask the server to run a rm -rf. I don't know if any of them have done this.

Answer 2

You are connecting to a remote system with the "nautilus" file manager or similar, using an ssh:// URL, with the sftp protocol.

My version of nautilus refuses to move such a remote directory to local trash. Moving a remote directory tree to local trash would be slow, it would have to download all the files before deleting them.

My nautilus is just deleting the files. The sftp protocol did not have any 'recursive delete' function until earlier this year (2012 R1). You're not using this newer sftp system, and nautilus probably doesn't know about it yet. So the file manager must list all the files, and delete them one at a time. It receives a confirmation message for each file that the deletion has been done, before going on to the next file. So the minimum time to delete a file is like your normal ping time to the server (or worse).

This one-at-a-time remote delete is much slower than running rm -rf /whatever or even rm -vrf /whatever over a normal ssh connection. I'm deleting gcc source code as a test case, and it estimates 40 minutes to go for these 28300 files. nautilus is using only 2% CPU so it's clearly not CPU bound drawing the GUI.

The problem has nothing to do with the GUI, it's due to a weakness in the (old) sftp protocol: there is no recursive delete function. But, this is why I use the command-line! No self-respecting hacker would wait 40 minutes for this!!

A file manager could delete files reasonably quickly while showing what files are being deleted, if it was using something like rm -vrf /whatever. Some servers provide sftp access but not full ssh access. Nautilus seems to be assuming the worst, and using only sftp.

Answer 3

When you do rm via the command line, all it does is recursively delete the files. The OS doesn't have to load the GUI, load the progress bar, update you as the files are recursively deleted, and close upon completion. While GUIs are nice-looking, they're not necessarily the best tools for system administration. Here's an interesting example, although it's not quite related.