Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Something I wondered about as I was deleting a dozen or so images from my computer: With a quick rm -rf command on the directory's contents, all the images were gone in a snap. When I drag the same dozen or so images to a trash can/recycle ban, it takes sometimes 10 seconds or more.

Now I'm sure some of it comes from the overhead of the GUI and such, and some of it may be the fact that the file still "exists" in some form if it's put into the recycle bin, but is there anything else that accounts for such a huge time disparity? Are "rm" and "delete" just such fundamentally different commands so I'm trying to compare apples and oranges?

share|improve this question
1  
It's true on windows as well, presumably for the same reasons given below. –  Chris H Jun 13 at 15:25

1 Answer 1

up vote 37 down vote accepted

As you rightly noticed the GUI does more than just "delete" the files.

$ rm -rf 

just recurses into folders deleting the files and folders it finds in there.

The GUI first scans the whole tree to work out what there is there (so it knows how much it has to do to draw the pretty bar), then it recurses through the tree again moving the files from the current location to the location of the trash can files for your specific GUI. That moving takes longer, as it has to first generate a new unique filename, link the file in the trash folder, then unlink it from the current folder, and update an index of where the files came from so they can be "undone" - many operations instead of just one.

For instance, on Gnome 3 the files are moved to the location:

~/.local/share/Trash/files/<filename>[.<version>]

Where filename is the original file name, and version is an incrementing version number to ensure the file is unique (the first file instance has no version number). Associated with that is a .trashinfo file stored in the folder:

~/.local/share/Trash/info/<filename>[.<version>].trashinfo

This file contains the original path of the file before deletion, as well as the date and time this file was deleted.

All these extra operations, which have to be performed on each and every individual file in the tree you are deleting, ensure that you are able to restore any file from the trash can, and that you are able to delete files named the same from the same location and still restore earlier versions.

None of that is done with a simple rm or mv command.

share|improve this answer
1  
Hey, who deleted all the comments? We were just figuring out that this answer might be wrong. At least trash-cli doesn't seem to do it recursively. When deleting a folder, does Gnome 3 really put a .trashinfo file recursively for each subfolder and all containing files? –  mb21 Jun 16 at 11:03
    
Guess it got too rowdy for them! ;-) –  Jordan Plahn Jun 16 at 11:46

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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