5 ms·
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.
by tedunangst 4y ago
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.
- bee_rider 4y agoThat’s pretty outside-the-box and fun.
- eyelidlessness 4y agoAmusingly it’s basically how most GUI desktops “delete” stuff, they just put a confirmation in place of the &&
- HeavyFeather 4y agoI don't think any GUI move items before a confirmation, so I don't see the link at all.
- eyelidlessness 4y agoThey 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.
- Dylan16807 4y agoWindows, 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.
- ElectricalUnion 4y agoUnless 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.
- HeavyFeather 4y agoThat'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 `&`
- bscphil 4y ago> 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.
- eyelidlessness 4y agoProbably 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.
- adr1an 4y agoExactly, 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...
- edgineer 4y agoWhy would running mv before rm be faster? On what file systems is this true?
- adrianmonk 4y agoThe 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.
- jeffrallen 4y agoAnd 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).
- aix1 4y agoPlus, if there's a complex directory tree, rm has to traverse it (to deal with all the metadata) while mv doesn't.
- jeffreygoesto 4y agoIt's not faster, just somewhere else.
- WJW 4y agoI 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.
- noam_k 4y agoVery 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 https://abramov.io/rust-dropping-things-in-another-thread
- renox 4y agoYes, 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.