5 ms·

I feel like if you use `rm -rf` particularly `--force` with privileges, it shouldn't be the job of Unix to stop you. Also tangentially, if you don't have a sen

I feel like if you use `rm -rf` particularly `--force` with privileges, it shouldn't be the job of Unix to stop you. Also tangentially, if you don't have a sensible backup in place that would protect you from (or at least mitigate) a complete wipe of a single machine (or even all primary ones), you are doing something wrong.

eridius 11y ago
The problem with that is people are trained to use -f because it's so annoying to try and use rm without it. Really, the -f flag should just mean "don't ask for confirmation" and a separate flag should be required to mean something like "yes I do want to nuke my computer". And maybe there should be a flag that means "cross device boundaries", and by default it could refuse to delete anything that has a device number different than the argument it started with. That would at least prevent you from nuking your network-attached storage.
- rosser 11y ago
  This is probably a far better solution than trying to make rm smarter about which kinds of files it's somehow either "safe" or "unsafe" to unlink. Even then, though, you'd still get people who invoke it with "--across-devices --yes-i-really-mean-it" set, with unexpected and disastrous consequences. And then someone will come along and bitch that rm isn't safe enough yet again.
  - eridius 11y ago
    Well, the point is that --across-devices won't be a flag you use as a matter of habit, it's something you'll only use when rm tells you it won't cross the device boundary and you realize that, yes, you really do want to delete across a device boundary. So you'll only add it in the specific cases where it's warranted, and you'll have already tried rm without it (to verify that you're deleting the right thing). Come to think of it, I don't think I've ever used rm to delete across device boundaries. It just doesn't seem like an action you usually want to take.
  - blakeyrat 11y ago
    ... so then you change it to be more safe yet again. I don't understand this attitude. Of course software isn't perfect; it's not even close, it's pretty awful. But the best thing about it: it's malleable. When things don't work, you change them to work better.
    - rosser 11y ago
      When things don't work, you change them to work better. I'd submit that adding layer upon layer of complexity to prevent all the myriad stupid things people might do using a particular piece of software isn't axiomatically "better". Maybe if lives depend on its correct function, it's worth it, but that kind of strict requirements gathering and execution is well-understood by the people who live in that world. Making sure that J. Random DevOps Dude doesn't foot-gun himself when he's paid to know better isn't that.
      - Avshalom 11y ago
        But J. Random DevOps doesn't foot-gun himself he foot-guns the whole Op. You can fire him because it turns out he didn't know better but it's not going to fix the problem he created, the problem now affecting the whole company.
        rosser 11y ago
        Believe me, I know this. Entirely too well, in fact. At my last job, the senior DevOps dude foot-gunned the entire company, by running a read-write disk benchmark (using fio(1)) against the block device (instead of a partition, which, while still stupid, would at least not have been actively destructive) on both my master and all of my slave PostgreSQL hosts. At the same time. And, of course, without telling anyone what he was doing, so the first inkling I had that there was a problem was about 20 minutes later, when I started getting a steadily increasing number of errors suggesting disk corruption. How does one make such a tool drool-proof enough to prevent that kind of idiocy? Please, help me figure that out. And then give me a time machine, because that was a 16-hour day I'd really rather not have experienced. And, no, the right move is generally not to fire the jackass who makes that kind of mistake. In my case, above, the company spent about three quarters of a million dollars (just in revenue, never mind how much time was burned in meetings about the incident, my efforts to fix the problem, as well as his and the rest of his team's efforts, and so on) teaching him never to do that again. You don't buy lessons that expensively and then let someone else benefit from them. (That said, he did get fired several months later for telling the entire engineering lead team to fuck off, in so many words, for their having made a perfectly reasonable request, which was entirely within his responsibilities, and his skills, to satisfy.)
- ArkyBeagle 11y ago
  You should not use it the first time and verify that you actually need it. The second's pause may save your data :) If you're feeling rash, get up and walk around until it passes.
- kruczek 11y ago
  Well, there is "cross device boundaries" flag, but not enabled by default: "--one-file-system when removing a hierarchy recursively, skip any directory that is on a file system different from that of the corresponding command line argument"
packetslave 11y ago
Bingo. See also, "the drill story": When I was in seventh grade, I took an Industrial Arts class ("woodshop"). The first few weeks of the course were spent going over safety of the machinery. In particular, I remember a heavy-handed message that Mr. Hopfer gave at the drill press: This is a piece of industrial machinery. It is not a toy. If you put your hand on the stage and lower the bit, the machine will not jam up and make funny noises because it is too difficult. Instead, it will drill a hole through your hand. That is what makes it useful. If it didn't do that, you wouldn't be able to cut through wood.
- Scriptor 11y ago
  Luckily for us, computers are slightly more sophisticated than drills and we can incorporate sane safety checks with relative ease. In this case people are just asking for an explicit flag in the rare situation when they do want to delete everything.
- entee 11y ago
  There are actually ways to make it so it will in fact stop when contact with one's hand (for saws but you could see an analogous system for a drill press): http://www.sawstop.com/why-sawstop/the-technology http://www.sawstop.com/why-sawstop/the-technology Just because people should use something responsibly doesn't mean one shouldn't try to improve its inherent safety.
  - AlgorithmicTime 11y ago
    That will also stop for wet wood, which is annoying.
  - makomk 11y ago
    That will also apparently stop when in contact with wood that's recently been cut down or is damp, destroying the (expensive) brake and blade in the process. It even has a bypass mode for that reason.
    - kabr 11y ago
dghughes 11y ago
> I feel like if you use `rm -rf` particularly `--force` with privileges, it shouldn't be the job of Unix to stop you. I agree, that's what's so good Unix and GNU-Linux the freedom of root to do anything even major mistakes.
cmcginty 11y ago
I really hate this type of attitude. Just because .0001% of users want to do something, doesn't mean the other 99.9999% need to suffer for it. Are you against aircraft collision avoidance too? If your pilot wants to fly into another plane, then the guidance system shouldn't try to stop him, right?

eridius 11y ago

The problem with that is people are trained to use -f because it's so annoying to try and use rm without it. Really, the -f flag should just mean "don't ask for confirmation" and a separate flag should be required to mean something like "yes I do want to nuke my computer". And maybe there should be a flag that means "cross device boundaries", and by default it could refuse to delete anything that has a device number different than the argument it started with. That would at least prevent you from nuking your network-attached storage.

rosser 11y ago
This is probably a far better solution than trying to make rm smarter about which kinds of files it's somehow either "safe" or "unsafe" to unlink. Even then, though, you'd still get people who invoke it with "--across-devices --yes-i-really-mean-it" set, with unexpected and disastrous consequences. And then someone will come along and bitch that rm isn't safe enough yet again.
- eridius 11y ago
  Well, the point is that --across-devices won't be a flag you use as a matter of habit, it's something you'll only use when rm tells you it won't cross the device boundary and you realize that, yes, you really do want to delete across a device boundary. So you'll only add it in the specific cases where it's warranted, and you'll have already tried rm without it (to verify that you're deleting the right thing). Come to think of it, I don't think I've ever used rm to delete across device boundaries. It just doesn't seem like an action you usually want to take.
- blakeyrat 11y ago
  ... so then you change it to be more safe yet again. I don't understand this attitude. Of course software isn't perfect; it's not even close, it's pretty awful. But the best thing about it: it's malleable. When things don't work, you change them to work better.
  - rosser 11y ago
    When things don't work, you change them to work better. I'd submit that adding layer upon layer of complexity to prevent all the myriad stupid things people might do using a particular piece of software isn't axiomatically "better". Maybe if lives depend on its correct function, it's worth it, but that kind of strict requirements gathering and execution is well-understood by the people who live in that world. Making sure that J. Random DevOps Dude doesn't foot-gun himself when he's paid to know better isn't that.
    - Avshalom 11y ago
      But J. Random DevOps doesn't foot-gun himself he foot-guns the whole Op. You can fire him because it turns out he didn't know better but it's not going to fix the problem he created, the problem now affecting the whole company.
      - rosser 11y ago
        Believe me, I know this. Entirely too well, in fact. At my last job, the senior DevOps dude foot-gunned the entire company, by running a read-write disk benchmark (using fio(1)) against the block device (instead of a partition, which, while still stupid, would at least not have been actively destructive) on both my master and all of my slave PostgreSQL hosts. At the same time. And, of course, without telling anyone what he was doing, so the first inkling I had that there was a problem was about 20 minutes later, when I started getting a steadily increasing number of errors suggesting disk corruption. How does one make such a tool drool-proof enough to prevent that kind of idiocy? Please, help me figure that out. And then give me a time machine, because that was a 16-hour day I'd really rather not have experienced. And, no, the right move is generally not to fire the jackass who makes that kind of mistake. In my case, above, the company spent about three quarters of a million dollars (just in revenue, never mind how much time was burned in meetings about the incident, my efforts to fix the problem, as well as his and the rest of his team's efforts, and so on) teaching him never to do that again. You don't buy lessons that expensively and then let someone else benefit from them. (That said, he did get fired several months later for telling the entire engineering lead team to fuck off, in so many words, for their having made a perfectly reasonable request, which was entirely within his responsibilities, and his skills, to satisfy.)
ArkyBeagle 11y ago
You should not use it the first time and verify that you actually need it. The second's pause may save your data :) If you're feeling rash, get up and walk around until it passes.
kruczek 11y ago
Well, there is "cross device boundaries" flag, but not enabled by default: "--one-file-system when removing a hierarchy recursively, skip any directory that is on a file system different from that of the corresponding command line argument"

packetslave 11y ago

Bingo. See also, "the drill story": When I was in seventh grade, I took an Industrial Arts class ("woodshop"). The first few weeks of the course were spent going over safety of the machinery. In particular, I remember a heavy-handed message that Mr. Hopfer gave at the drill press: This is a piece of industrial machinery. It is not a toy. If you put your hand on the stage and lower the bit, the machine will not jam up and make funny noises because it is too difficult. Instead, it will drill a hole through your hand. That is what makes it useful. If it didn't do that, you wouldn't be able to cut through wood.

Scriptor 11y ago
Luckily for us, computers are slightly more sophisticated than drills and we can incorporate sane safety checks with relative ease. In this case people are just asking for an explicit flag in the rare situation when they do want to delete everything.
entee 11y ago
There are actually ways to make it so it will in fact stop when contact with one's hand (for saws but you could see an analogous system for a drill press): http://www.sawstop.com/why-sawstop/the-technology http://www.sawstop.com/why-sawstop/the-technology Just because people should use something responsibly doesn't mean one shouldn't try to improve its inherent safety.
- AlgorithmicTime 11y ago
  That will also stop for wet wood, which is annoying.
- makomk 11y ago
  That will also apparently stop when in contact with wood that's recently been cut down or is damp, destroying the (expensive) brake and blade in the process. It even has a bypass mode for that reason.
  - kabr 11y ago

dghughes 11y ago

> I feel like if you use `rm -rf` particularly `--force` with privileges, it shouldn't be the job of Unix to stop you. I agree, that's what's so good Unix and GNU-Linux the freedom of root to do anything even major mistakes.

cmcginty 11y ago

I really hate this type of attitude. Just because .0001% of users want to do something, doesn't mean the other 99.9999% need to suffer for it. Are you against aircraft collision avoidance too? If your pilot wants to fly into another plane, then the guidance system shouldn't try to stop him, right?