As a linux neophyte, I once struggled to remember whether the trailing slash on a directory was important. So I typed "rm -rf", and pasted the directory name "schoolwork/project1 " (with a trailing space), but then I waffled and decided to add a trailing slash. So I changed it to "rm -rf schoolwork/project1 /".

That's my theory as to what they did.

  rm -Rf test /
  rm: it is dangerous to operate recursively on ‘/’
  rm: use --no-preserve-root to override this failsafe

GNU rm, but I don't know when it was introduced.

Quick googling around, and it seems like this behavior (in Ubuntu) changed somewhere near the end of 2008: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/174...

tl;dr That's when coreutils Ubuntu package switched from "--no-preserve-root" to "--preserve-root" by default.

This is relatively recent, and caused quite a stir when it was introduced. Certainly not around during Toy Story 2.

edit: More info:

https://lwn.net/Articles/327141/

One feature I've always wanted is to make a directory non-deletable without otherwise changing the directory's functionality. So if I do "rm -rf ~/work" I don't lose anything, but I can still do "touch ~/work/whatever". As far as I know, this is impossible.

You don't actually need write access to a file/directory to delete it. You only need write access to the parent (removing or adding a file modifies the container, not the contained).

Remove write access to the parent directory, while keeping traversal and read rights, and you'll be sorted.

But then I can't add files to my home directory...

So don't put the stuff you want to protect this way in your home directory, but somewhere else, and symlink the relevant directories to your home directory.

Quite clumsy, but I guess it works. I'll keep it in mind, thanks for the idea.

You said it was impossible. I simply indicated it wasn't.

The question was perhaps imprecisely phrased, but I think you can figure out what I'm trying to accomplish.

# mkdir /tmp/foo

# touch /tmp/foo/.immutable

# chattr +i /tmp/foo/.immutable

# rm -rf /tmp/foo

It's not EXACTLY what you asked for, but the .immutable file cannot be deleted until you call chattr -i on it, which protects the directory....

That doesn't protect siblings of <foo/.immutable>...

If I remember correctly, they were using Solaris at the time, and I know for sure that Solaris did not have this safety net, nor did Linux at the time. The requirement of --no-preserve-root was introduced almost a decade later.

obligatory call for everyone to use safe-rm [1].

it's one thing to shoot yourself in the foot, but without safe-rm you (or someone else less cautious) will eventually fire the accidental head-shot. it's happened to me a couple times; but never again since I started using safe-rm everywhere.

[1] http://serverfault.com/questions/337082/how-do-i-prevent-acc...

I'll add another obligatory, make sure you have a working backup system.

And that you already tried to restore from it

It's more likely they wanted to remove all hidden directories from their home directory, and ran `rm -rf .*`.

Under some shells (eg bash) that will expand to include `..` and `.`.

The last time it happened to me, it was caused by a space. Instead of rm -rf toto٭, I had rm -rf toto ٭.

Hopefully, it was not at the root directory and we have frequent snapshots.

I have totally never done that. If I had done that, I might have been saved by a lack of permissions. Like if I was on a mounted external drive, so not in my home directory and it didn't get too far.

Edit: What would have been much more worse, if I had done it, would have been

    rm -rf ~ /foo

instead of

    rm -rf ~/foo

Such a bug was in an Nvidia driver install script a few years ago:

  rm -rf /usr /lib/modules/something/something

Bumblebee specifically, https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/commi... is the fix. Pretty sure Steam had the same issue early in their linux release, probably lots of other programs too.

Yes, I specifically remember a lot of hub bub about Steam deleting entire home directories if a path was input incorrectly. Glad that never bit me.

And also iTunes, back in the early days of OS X:

https://www.wired.com/2001/11/glitch-in-itunes-deletes-drive...

This is why I never use bash for scripting, and opt for Ruby instead.

You can use the `Pathname` class to treat paths as objects, which you can concatenate only valid paths with. Aside from obviously all the other sanity-saving features.

Same. Ruby isn't my preference, but I avoid bash scripting whenever possible. I see very little need to use it when practically every machine requires Python, Ruby, and other high-level dynamic languages as pre-requisite for some basic software that's included by default. I respect bash, but it's from a bygone time. Why deal with the esoteric one-character test operators, the nitpicky spacing issues, etc? Use modern, readable, testable code. So much nicer and easier to read and work with that way.

I'd love to see someone deploy a Python or Ruby-based shell. I'm sure these are available, but they're not widely used.

Bash may be worse than Ruby or Python for scripting, but it's far better as an interactive shell.

And I'm quite happy not having shell use hold back evolution of Ruby or Python, and not having drama like Ruby 1.8 -> 1.9 or Python 2.x -> 3.x affecting shell use.

That's mortifying!

Or, maybe you forget which directory you are in, and delete the wrong one that way: `rm -rf ../*` when you think you're in `/mnt/work/grkvlt/tmp` but are actually in `/mnt/work/grkvlt` at the time.

or perhaps it was the dreaded "rm -rf ${DIR}/*" when $DIR is not defined.

Safe shell coding tip #10451: Variables containing directories always have to end in a slash, and paths may never be built using variables and slashes.

Why is that more likely?