I recently wrote a script that may help:

It assumes you'll run it with 2 argument such as 'rm -rf /', I have tested it some, and it works reasonable well. Will not work with question mark wildcards '?', it's tricky to work with those, but it is possible, maybe using 'stat -c %n' to find out what you really want to delete, but I'll assume the user is not foolish enough to use '?' along with 'rm -rf' as root.

I feel bad for you. Really. Does rm require verification under the root account in Debian? Under root in Fedora, there's an alias for rm that includes the -i (interactive) switch.

If so, you did a onesy-twosy. First, you ran the command without verifying your current location. Second, you verified that, yep, I want to rm -rf my root directory.

Ouch.

Don't worry. It's understandable, and I'm not getting on your case. Motor reflex played in that.

I do hope you recover your data.

I just tried creating a directory under my user account, then 'chmod -w' on it, which should have rendered the directory read-only, but still usable. Unfortunately, I was still able to delete it. Goes against my logic.

Anyway, the test was to see if it would be possible to read-only the directories at the root level to help prevent this type of thing from happening. Apparently, it won't work. And if it did work, I guess that might have been implemented a long time ago. Oh, well.

No, that's not it at all. What he probably did was accidentally hit Enter without finishing to write the command, which I have done as well. I've also accidentally typed in incorrect locations several times because I forgot to include a '.' for current directory. So I did 'rm -rf /usr/local/bin/whatever' when I meant 'rm -rf ./usr/local/bin/whatever', this was while I was working with a package.

So, I don't agree with your argument. There is also no reason to be able to delete top level directories in 99.9 % of all cases. Why give you the power to obliterate your system when chances are you will accidentally obliterate your system and may never have to delete any top level directory. Yes, you should be careful, but I'm not always 'alert', sometimes in fact, I'm not even awake while using my computer, so it can happen. Of course, you're probably a much more experienced Linux user, yes, you've been working with it so long you will never make such a stupid mistake again. Much like if you're an experienced C programmer / guru you will never dereference a null pointer, that just can't happen to a guru.

Running 'chmod -w' on a directory will not prevent you from removing it. What it does is prevent you from removing (or adding) anything to it. However, root is not prevented from writing to a directory that is set to not be writable.

HTH

Forrest

A few quotes to lighten the mood..

"to err is human, to really foul up requires a computer"
"experience is what you get, when you don't get the results you expected..."

Yes the files would most likely all be recoverable if you pulled the plug and remounted the drive read only. Reloading the box will most likely be a lot less work. I would only bother with attempting to recover the files if they were critical data.


No, I DON'T want an OS to decide for me what is safe and what is not, and to second guess every command I type. If I wanted that annoying interplay with the OS, I'd just go buy Vista..

I think it's quite a strech comparing something like this to vista's yes/no whenever you try to do anything.

rm -rf ./* is a command you are likely to never execute on / or any of the first level directories excluding tmp intentionally, so why not a short warning?

I'm trying to think of a scenario where this would apply...
You've chrooted into a client to fix something, after two hours you realize all is lost, and do a rm -rf while saying something very PG16 rated?

Does the "are you sure?" question really make it any worse at this point?

Did I have an argument? I am sympathetic to the OP. I know things happen. It's very easy to press buttons automatically without thinking about it. Motor reflex action.

I don't understand. Are you saying there should be something in Linux that disallows you to "rm -rf /"?

That's one of the powers of root. If you're root, you're omnipotent. You'd better know, and be paying attention to, what you're doing, else "rm -rf /" happens. But the "rm -i" option could have saved the OP, if the -i was implemented, and he was paying attention.

Me? Experienced? Not by a long shot! I've only been working with Linux for 2-3 years. Whenever I plan to blow away a directory with rm -rf, I think really hard. Almost scared ****less to press enter. I stare at the command, and verify my pwd over and over. Almost ridiculously obsessive. If someone was standing behind me they'd slap the back of my head and tell me to get on with it.

I've been in situations where I've accidentally formatted incorrect partitions on Windows servers, etc. I am far from perfect.

I have a couple of comments

1. if I'm worried about an rm cmd, I'll try ls with the same params to check
2. What you can do is alias rm="rm -i" for root only in the .bash_profile . However, iirc, it will ask for confirmation for each file, so if you are sure you want a mass delete, you can either
echo y|<your rm cmd>
or
temporarily re-alias it
alias rm="/bin/rm" , run the cmd, then logout or unalias it.

Its not the sort of mistake you make often...

I don't think anyone wants to make anything absolutely impossible, even hosing your own system. But it should also be possible to configure things to make it easier to avoid making the most egregious mistakes. A simple check-and-confirm when trying to delete important system files would go far in avoiding big accidents like this. And of course it should be bypassable if for some reason you really want to live on the edge.

It shouldn't be hard to create a shell function or script to compare the files to be deleted with a master list, and have it throw a warning or something when they match.

Yea, shortly after I did it, I planned that once I got it up and running I would create a patch for 'rm' that'll never allow me to make that mistake again.

Anyway, I know that there wasn't a warning message before it started. I think this was because I typed 'rm * -rf' instead of 'rm / -rf', but I'm not entirely sure about that. I'll have to look at it later.

A good thing about the whole situation is that the computer isn't anything important. It's several years old and my primary purpose is using it as a sandbox machine, which in time, got a secondary purpose as a torrent machine.

It's going to take a couple of hours to reinstall and setup everything but I've done it enough times that I think I can do it blindfolded by now.

If anything, it was a very educational (and frustratingly at the time) experience.

@ SlowCoder

I almost feel sorry for you.

Time to un-subscribe to the thread, methinks.

rm is one command, there are a lot others that can kill your system:

Hummmm

Try to never run as root, only when really needed.

It just seems that 'rm' would be the most common. Now that you mention it, I wonder if it's possible to run this as root (if your drive were /dev/hda)?
Hopefully, I won't be the unlucky one to do that though.

Yes, it is very possible to do something like that. If there's any one command more risky than rm, it's that one. 'dd' does stand for 'data destroyer' after all.

I've never destroyed a main system drive with it, but I have accidentally wiped an external drive that way.