Hacker News Reader

Comment by tedunangst | Hacker News Reader

If you need a large sub tree gone, mv dir .old-dir && rm -r .old-dir & works pretty well. Faster even than an optimized parallel unlinker.

View on HN

Very nice!

This reminds me of a similar trick to speed up deallocations by moving them to a new thread: https://abramov.io/rust-dropping-things-in-another-thread

Probably good enough for most use cases, and it’s basically what I do when I’m sure it’ll succeed. And a lot of times I just do the mv and worry about cleanup later, because disk space is cheaper than recreating whatever I might yeet by mistake.

Exactly, I use 'gio trash' on Linux for this reason. And I let a cronjob do removal of all the .Trash with find -ctime +180 -exec rm...

Why would running mv before rm be faster? On what file systems is this true?

The idea is to rename it so that you don't have to wait for it to be deleted. You can let the deletion run in the background once it has been moved out of the way.

And to be totally, ridiculously pedantic (this is HN after all) mv is a single atomic metadata operation in the filesystem, which will almost certainly go into the filesystem log without any wait on i/o. A big rm is going to generate enough metadata churn that the filesystem log will need to be synced to hardware at least once, and then you've got 2 or 3 orders of magnitude more time to wait (per sync).

Plus, if there's a complex directory tree, rm has to traverse it (to deal with all the metadata) while mv doesn't.

It's not faster, just somewhere else.

I think you missed the `&` at the end of the rm command, which runs it as a background process. It's not faster in total time, but it will allow the user to continue inputting new commands much sooner.

Yes, I use this trick at work to remove the generated build directory. IMHO this behaviour should be added to 'rm', but not by default due to the background work triggered.

That’s pretty outside-the-box and fun.

Amusingly it’s basically how most GUI desktops “delete” stuff, they just put a confirmation in place of the &&

I don't think any GUI move items before a confirmation, so I don't see the link at all.

They almost universally do! They move stuff to a designated trash or recycle bin or whatever to stage for final deletion when you commit to it.

Windows, if asking is enabled, will ask before moving into the recycle bin.

Once the file is in the recycle bin, it will probably be months before final deletion happens, and windows will not ask before doing so.

Unless you happen to start to run low on disk space; at that point, Storage Sense will kick in and start complaining about it - if you enable it without changing standard settings it deletes "trash bin" files every 30d.

That's a very liberal way to define "confirmation", especially since modern OSes will delete trashed items on a rolling 30-day basis, without any further action.

To rephrase:

> mv dir .old-dir && rm -r .old-dir &

it's how most GUI desktops “delete” stuff, they just run the two actions separately

It's kind of a stretch anyway since the core idea of the command was the final `&`

> modern OSes will delete trashed items on a rolling 30-day basis, without any further action.

Hmm, the best I can find, no OS does this by default although all of them are capable of doing it.

Reply on news.ycombinator.com