4 ms·

This is precisely why I always `-v` when `rm`ing recursively. It might be closing the barn door after the proverbial horse has bolted; but at least the fuck up

This is precisely why I always `-v` when `rm`ing recursively. It might be closing the barn door after the proverbial horse has bolted; but at least the fuck up is visible and in some circumstances you have a fighting chance to kill `rm` before too much damage has been done.

medstrom 5y ago
Is there a rm variant that bundles an undo command?
- hnlmorg 5y ago
  There's a few ways to solve this: + a command that doesn't actually delete but rather moves the file to a trash folder that gets emptied periodically (this is exactly how a desktop environments work) + a command that removes the inode but leaves the data intact. This could get pretty messy pretty quickly on SSDs. + `rm` behaves as normal but you restore the file using forensic tools / file recovery tools. Similar problem with SSDs as above. + `rm` behaves as normal but you run a snapshotting file system such as ZFS (maybe even have a wrapper function around `rm` to take a snapshot before running `/bin/rm`). Any "undo" would be recovering from snapshot. + `rm` behaves as normal but you restore from backup. Which isn't really a solution but still worth presenting here given the range of options I've presented. Personally I went with ZFS where possible. If recovery is tricky and I'm throwing wildcards at the problem then I'll do an `ls` first just to double check I'm not doing anything stupid.
  - medstrom 5y ago
    There are a number of commands named "trash". But I don't want to keep in mind to execute "trash-empty" occasionally, especially when rm'ing the same large file several times (say, ones made by "dd if=/dev/zero ..."). So either a cron job for emptying the trash, or I think more elegantly, have "trash" just empty the trash before trashing the next file (i.e. there is only ever one thing in the trash).
iamtedd 5y ago
How about just don't use -f all the damn time?
- hnlmorg 5y ago
  I neither use -f "all the damn time" and nor do I appreciate that baseless accusation. Furthermore -f has literally nothing to do with my comment about -v
  - iamtedd 5y ago
    I was building on your response to the GP. Instead of using -v to see files as they're being deleted, wouldn't it be safer to not use -f, which will not delete important files in the first place? I see it countless times all over the Internet - everyone is constantly using -rf no matter the situation. The most common horror story in the article is from people using -rf and losing data. The whole point of -f is so normal usage (without -f) doesn't delete important files.
    - hnlmorg 5y ago
      You misunderstand what -f does, however you are right that it is used all over the place by default and it does add more risk than not using -f. However you're wrong that the lack of -f is risk free. Unfortunately even without including the -f flag it is still possible to delete "important" files given that "important" can mean a spectrum of things, both in terms of file system metadata and in terms of personal worth. In fact `rm`doesn't even try to understand what an important file is (and why should it?). All the -f flag does is ignore prompts and non-existent files: $ man rm ... -f, --force ignore nonexistent files and arguments, never prompt ... I think it also overrides skipping the removal of files that don't have a write bit set (despite that not being explicit in the man page) but even if that's also true, you're going to have a crap load of important files that are still writable. Thus it's still quite possible to trash your host using `sudo rm -r /` You might then say "so you shouldn't use sudo either" and that's true. But going back to my earlier point about "what is an important file?", you're still going to have lots of "important" files on your system that aren't root owned. Maybe development files. Maybe personal files. Thus it is trivially easy to remove wanted files with a careless `rm -r ~/$UNSET` (a bug in Steam's Linux installer once did this in fact). So the benefit of -v isn't mitigated by the non-inclusion of -f. Not even slightly.

medstrom 5y ago

Is there a rm variant that bundles an undo command?

hnlmorg 5y ago
There's a few ways to solve this: + a command that doesn't actually delete but rather moves the file to a trash folder that gets emptied periodically (this is exactly how a desktop environments work) + a command that removes the inode but leaves the data intact. This could get pretty messy pretty quickly on SSDs. + `rm` behaves as normal but you restore the file using forensic tools / file recovery tools. Similar problem with SSDs as above. + `rm` behaves as normal but you run a snapshotting file system such as ZFS (maybe even have a wrapper function around `rm` to take a snapshot before running `/bin/rm`). Any "undo" would be recovering from snapshot. + `rm` behaves as normal but you restore from backup. Which isn't really a solution but still worth presenting here given the range of options I've presented. Personally I went with ZFS where possible. If recovery is tricky and I'm throwing wildcards at the problem then I'll do an `ls` first just to double check I'm not doing anything stupid.
- medstrom 5y ago
  There are a number of commands named "trash". But I don't want to keep in mind to execute "trash-empty" occasionally, especially when rm'ing the same large file several times (say, ones made by "dd if=/dev/zero ..."). So either a cron job for emptying the trash, or I think more elegantly, have "trash" just empty the trash before trashing the next file (i.e. there is only ever one thing in the trash).

iamtedd 5y ago

How about just don't use -f all the damn time?

hnlmorg 5y ago
I neither use -f "all the damn time" and nor do I appreciate that baseless accusation. Furthermore -f has literally nothing to do with my comment about -v
- iamtedd 5y ago
  I was building on your response to the GP. Instead of using -v to see files as they're being deleted, wouldn't it be safer to not use -f, which will not delete important files in the first place? I see it countless times all over the Internet - everyone is constantly using -rf no matter the situation. The most common horror story in the article is from people using -rf and losing data. The whole point of -f is so normal usage (without -f) doesn't delete important files.
  - hnlmorg 5y ago
    You misunderstand what -f does, however you are right that it is used all over the place by default and it does add more risk than not using -f. However you're wrong that the lack of -f is risk free. Unfortunately even without including the -f flag it is still possible to delete "important" files given that "important" can mean a spectrum of things, both in terms of file system metadata and in terms of personal worth. In fact `rm`doesn't even try to understand what an important file is (and why should it?). All the -f flag does is ignore prompts and non-existent files: $ man rm ... -f, --force ignore nonexistent files and arguments, never prompt ... I think it also overrides skipping the removal of files that don't have a write bit set (despite that not being explicit in the man page) but even if that's also true, you're going to have a crap load of important files that are still writable. Thus it's still quite possible to trash your host using `sudo rm -r /` You might then say "so you shouldn't use sudo either" and that's true. But going back to my earlier point about "what is an important file?", you're still going to have lots of "important" files on your system that aren't root owned. Maybe development files. Maybe personal files. Thus it is trivially easy to remove wanted files with a careless `rm -r ~/$UNSET` (a bug in Steam's Linux installer once did this in fact). So the benefit of -v isn't mitigated by the non-inclusion of -f. Not even slightly.