The classic Unix horror story

I've never actually been bitten by rm (or done anything remotely this badass) but in college I did have a bad Unix moment:<p>Late at night, I was tarring up a finished project right before emailing it to my professor. I ran:<p><pre><code> tar -cvf *.cpp *.h something.tar </code></pre> instead of:<p><pre><code> tar -cvf something.tar *.cpp *.h </code></pre> It happily wrote most of my project into a tar file on top of the first source file, then complained that something.tar didn't exist. I overwrote "array.cpp" or something like that, and had to rewrite it (this was before I used source control for anything, and a large part of why I learned to use source control).<p>Writing this comment, I had to look up the order of the parameters to tar; I still can't remember. Stupid tar.

Is there a "social news sites classics" directory yet? I would love to see reposts of oldies no longer justified due to a good directory of these things, prominently linked.<p>Pretty please do not create such a directory in this comments thread.

Man, how many times is this story going to be submitted?

I might have misunderstood the story, but if this happened to me today on my gear I would simply turn it all off, connect that half-erased hard disk to another machine, mount it, and pull all the data off. And only after a lot of googling to see if some of the lost files could be "undeleted".<p>Salvaging the disk by recreating a minimalist system on it is heroic and hacky, but was that the only way?

Back in the dinosaur days I worked with DG minis running AOS/VS, a Multics descendant. From time to time an operator would run the equivalent of cd /; rm -rf, halting everything. The neat thing about the delete command was that would zap the PMGR, peripherals manager, quite early on; unable to communicate with the disks, the delete would fail. Generally one could then locate an older version of :PMGR to rename, then recover. Failing that, one could boot off a "systape" and recover.<p>Not as hard-core as the recovery through emacs, but greatly welcome under stress.

I don't agree with the following comment:<p>"Great programmers spend very little of their time writing code – at least code that ends up in the final product. Programmers who spend much of their time writing code are too lazy, too ignorant, or too arrogant to find existing solutions to old problems. "<p>I mean so... who's writing the code then? Who's writing the original code? I would call a clever programmer a great programmer. Just clever. and sometimes clever can get you into trouble. But just sometimes :)

My terrible UNIX, or really SunOS/Solaris moments have been:<p><pre><code> o typing 'halt' into the wrong xterm, shutting down well planners o and likely on the same network, jacking up the NIS+ on Solaris </code></pre> It's been a constant itch that I never did manage to understand what I was doing wrong, such that NIS+ wouldn't restart correctly.

I still remember my "rm -fr /" episode after almost 20 years. It was slightly different, something related to chmod'ing some files under /etc on an AIX server:<p><pre><code> $ cd /etc $ chmod 600 some_file * # instead of some_file.* </code></pre> oops... Thank God for boot diskettes.

Oh, how many of us (including myself) experienced such things, and yet we're unwilling to admit that there is something fundamentally wrong with tools that <i>just</i> do what we tell them to.

I'd say this is a classic Unix success story, told in the context of an almost horror. It shows how a serious understanding of Unix-foo can save the day when someone makes a mistake.

The Unix Haters' Handbook is worth looking up. I think it is out of print but the PDF is available for download.<p>My favourite from USENET is cleaning out <i>.o files after compiling C code but fat-fingering the SHIFT key and instead of typing<p>% rm -f \</i>.o<p>,typing<p>% rm -f *&#62;o<p>which gives you an empty directory and a zero length file called "o"<p>ah yes....

While part of a team of students at a hacking competition I was VNC'ed into an owned 2003 server, I was trying to get to the network settings properties menu, when my VNC session lagged and I clicked at the same time that my mouse reached the Disable interface.<p>Yeah ... I didn't live that one down, lost my team some points.

This reminds me of the faithful day when I finally stopped working as root all the time.<p>That happened right after typing<p><pre><code> cp backup.tar.gz /dev/sda </code></pre> That was fun. Also, back then I had no idea how easy it would have been to at least get the contents of that backup file back using dd

This makes Unix's orthogonality really clear. I'm fascinated the system was still able to run after taking that kind of a hit. Imagine what would happen to WIndows (immediately) if half the system (including key system binaries) were destroyed.

One time I did something like<p>$ chown -R terra_t.terra_t /<p>on a production system. Fortunately I was able to recover the permissions of most of the system files from the rpm database, and do the rest by hand...

My personal favourite is "rm -rf * .swp" instead of "rm -rf *.swp" or such.

An old story but still shocking.<p>One should be careful making such damage threats though, may end up with male appendage replacing rabbit foot on someones' keychain

Thank god Windows has the stupid and annoying file locking!

frequent automated offsite backups are your friend