Live data from Hacker News

Ooops.

github.com

71–80 of 247 posts

Re: Ooops.

#71
post #65

The reason we all know to be careful with rm -r is because of that one time we weren't. Me, it was the time I rm r'ed the MySQL data directory for my company's customer service management system. Oops. Thankfully we had a backup from the month prior, but I learned two things that day: a) be really careful with rm and b) take it on yourself to make sure IT is backing up stuff that you're messing with. You gotta hedge…

Was asked to uninstall IBM/Rational ClearCase from our source code repository server. Apparently at the time, Clearcase's installer NFS mounted 127.0.0.1:/ to a subdirectory. Don't ask me what brain-dead system designer thought this was a good idea.

So, I did a simple /etc/init.d/clearcase stop (not sure that is the exact name) and:

# rm -rf /opt/clearcase

(hmm... that seems to be taking a little too long to run)

Panic - then ctrl-C - it was too late, /opt/clearcase/foo was NFS mounted 127.0.0.1:/ and it had already trashed /bin, /sbin, /etc, /var, and most of /usr.

Luckily I had good backups, but we did spend the rest of the day rebuilding the source repository while the developers couldn't check in any code.

Re: Ooops.

#73
A couple months ago I had to recover some rm'd files by basically grepping 512-byte blocks on the file system for the file headers then writing out the next few KB to a file on a separate partition to manually go through..

My command sequence was more like this though, rather than a straight rm:

    find -name '*.java' | xargs grep --color 'something'
    # guh, get rid of these old copied .svn dirs polluting output
    find -name '.svn' | xargs rm -rf
    # now what was that..
    find -name '*.java' | xargs rm -rf
Forgot to edit the right side of the pipe back to the grep. Zealous use of the up-arrow burned me...

Re: Ooops.

#74
post #65

The reason we all know to be careful with rm -r is because of that one time we weren't. Me, it was the time I rm r'ed the MySQL data directory for my company's customer service management system. Oops. Thankfully we had a backup from the month prior, but I learned two things that day: a) be really careful with rm and b) take it on yourself to make sure IT is backing up stuff that you're messing with. You gotta hedge…

dead tired, 4am in the morning working on a client app for a huge client of theirs (I was subcontracting) was trying to remove everything inside a folder and instead of going

rm -rf ./*

I went

rm -rf . (can't get the wildcard thingamajig to show up)

It took me a second to understand why the command was taking so long to run, by the time I figured it out and killed the command, I had wiped out almost half of what was on the drive.

Biggest "oh. my. god" moment of my life. I think I had an actual panic attack for a bit even.

Luckily, media temple had a backup from just a few hours earlier (I was lucky, they only ran them periodically and it just so happened to fall on that day).

Re: Ooops.

#75
post #65

The reason we all know to be careful with rm -r is because of that one time we weren't. Me, it was the time I rm r'ed the MySQL data directory for my company's customer service management system. Oops. Thankfully we had a backup from the month prior, but I learned two things that day: a) be really careful with rm and b) take it on yourself to make sure IT is backing up stuff that you're messing with. You gotta hedge…

More than once I've made the mistake of running an UPDATE and forgetting the WHERE clause.

Re: Ooops.

#76
post #46

I learned a rather unusual trick to keep myself safe from unintended glob matches. It is not "fool"-proof, but it will probably dilute an unmitigated disaster into an incomplete disaster: Keep a file named -i in the sensitive directories. When glob picks it up, which should be fairly early, it will be treated like a command line argument. Has saved me on occasions. I also had a friend in school who used to, for whate…

I hate that feeling you get in the pit of your stomach after you realize what's happening.

Same thing when you forget the WHERE on a DELETE FROM.

Re: Ooops.

#77

Earlier quoted context omitted.

...my co-workers using windows ftfy.

Why would he need to explain it to the windows that are using his coworkers? Also, it's very unclear to me what that the situation you are describing entails. /s Grammatically, your sentence is no less ambiguous.

oh man, thursday evening, a couple of glasses of wine, and here I thought I was the grammar nazi :)

Re: Ooops.

#80
post #65

The reason we all know to be careful with rm -r is because of that one time we weren't. Me, it was the time I rm r'ed the MySQL data directory for my company's customer service management system. Oops. Thankfully we had a backup from the month prior, but I learned two things that day: a) be really careful with rm and b) take it on yourself to make sure IT is backing up stuff that you're messing with. You gotta hedge…

dead tired, 4am in the morning working on a client app for a huge client of theirs (I was subcontracting) was trying to remove everything inside a folder and instead of going rm -rf ./* I went rm -rf . (can't get the wildcard thingamajig to show up) It took me a second to understand why the command was taking so long to run, by the time I figured it out and killed the command, I had wiped out almost half of what was…

Wouldn't that just delete the folder instead of emptying it?
Post reply on HN