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?

  • 1
    You're being taken in by the pretty colours, that's all. rm isn't faster necessarily, but the file enumerator is. In the GUI, it has to show the user what files it's deleting, whereas rm doesn't show anything and does enumeration behind the scenes. The actual deleting, sans UI, is the same speed.
    – user3463
    Aug 6, 2012 at 5:45
  • Randolph: But everything behind the scenes remains the same?
    – Raymond
    Aug 6, 2012 at 5:54
  • 2
    Note: when someone on a Stack Exchange site suggests asking on a different one, they usually also flag it for migration, without your having to do anything. It's therefore best to wait for it to be migrated to the other site, rather than ask a new question. Aug 6, 2012 at 6:43
  • Mechanical snail: Gotcha, didn't know that before :P
    – Raymond
    Aug 6, 2012 at 6:48

2 Answers 2


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.

  • Thanks for the detailed explanation! The GUI is accessing the remote server's contents over SSH with Ubuntu's "Connect to Server" option. I can remove the files both ways, but I noticed the drastic difference in speed and wanted to find out why for curiosity's sake. I would upvote your answer but I don't have enough reputation... :P
    – Raymond
    Aug 6, 2012 at 6:55
  • 1
    I should add: even in the worst implementation I can imagine, with a round trip to the server for every file, 100 files per 2 minutes implies you have a 1.2sec ping time to the server, which is ridiculously slow. There may be more to your problem that we haven't uncovered yet.
    – Alan Curry
    Aug 6, 2012 at 8:01
  • That makes sense; the remote server I am working with is located in Korea with a public IP address, yet the network I am on is being routed to Taiwan from Korea and back (yay for large company networks... -_-) to the desktop in Korea, so there is noticeable lag even when using SSH through the Terminal.
    – Raymond
    Aug 6, 2012 at 8:09

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.

  • 1
    +1 for the sftp info. I didn't mention it in my answer only because I forgot it existed. Now I'm off to try to forget again.
    – Alan Curry
    Aug 6, 2012 at 8:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.