Slashdot Mirror
10 Computer Mishaps
Ant writes "ZDNet UK posted Ontrack Data Recovery's 2004 list of the 10 strangest and funniest computer mishaps... Some of them are funny!" My best mishap was installing the alpha video driver on an NT 3.51 box thinking that it was just an alpha driver. Of course since this Alpha meant DEC and this was an x86 box, the server barfed pretty hard. Also the time I spilled an 8oz glass of water on my laptop and lost all my email from 1994 to 1999 and my backup was corrupted. That I liked too.
The worst/oddest I've seen went something like this:
/.)"
1. Someone ran rsync with -r at the end, intending to do something recursive. This option was treated as an argument, causing a file called -r to be created. This was done in / on an HP-UX workstation.
2. Two years later, someone wrote a script to be run from cron that would run as root then change to a directory containing data files, erase them, and create new ones. This directory of data files was NFS mounted on the workstation in 1 above. Many, many other filesystems were also mounted on this workstation, all rw, all as root.
3. Some time after that, someone rebooted the workstation. Not All of the NFS mounts came up, so when the script in 2 ran as root and did not check to make sure the destination directory existed, it was not able to cd and ran in /
4. The script executed "rm -f *", intending to delete the data files. Unfortunately, the file called -r was still in / and was included in the argument list. Rm of course interpreted this as an option, so the command became "rm -f -r (everything else in
5. 3 and 4 happened on a saturday night when no one was around, so no one noticed all of the data disappearing until Monday, when it was all gone.
6. Several people had a very, very long day. Actually, several long days. A few weeks, actually.
Can you count the number of gross and avoidable administration mistakes, boys and girls?
-- Minds are like parachutes... they work best when open.
I have to agree with first posters... these aren't very good stories. But, thinking maybe it's phishing for better stories, I'll byte:
I once created an extremely complex script, crafted lovingly to do something at the time I'm sure I thought important. As always I incrememtally built and tested, assuring myself of one more self-anointed masterpiece. Finally, finished, as an afterthought...
I inserted a variable to point to a directory node below which I would clean up all of my work (even though I knew I had no need for the variable and would never tweak it). It was such a simple addition. No need to test.
Fired up the script, it ran a couple of seconds, I was prepared to enjoy the fruits of my labor. Hmmmm, I don't remember ANY of the test runs running so long. Why is the hard drive light flickering so much? And why still? And why so long?...
Yeah, the
command worked perfectly. Except I defined the variable initially as: cleanupdir=dirname
So, everything was lost except for the frigging "masterpiece".
Undaunted, (I'm no idiot, golllll!), I calmly inserted the QIC backup tape with my prerun backup.
No, wait!, I'll not be caught with that error again! I quickly edited the only remaining file in my tree of files, the offending script and smugly fixed the rogue spelling. I hadn't been working in this industry this long without knowing how to take safeguards!
Now, twenty minutes later, my script fixed... my files restored... let's try this again. Yeah... something about the chronology of fixing the script, then restoring the broken version over it from the backup tape. At least I proved the error was replicatable. So, I am an idiot afterall!
disclaimer: this happened over ten years ago, so I'm a bit short on exact detail of the snafu, but it really did happen. And, even though I repeated my idiocy, the fact I had the backup tape at all with only the one error to fix in the script saved my butt... so not all was lost in the lunacy.
Hate to do a "me too" post, but I did get desperate enough to try this once and it did work.
Had an old NT box that I had used long ago as a domain controller at home (don't ask). Sucker had been running a long time not doing much other than acting as a logon & print server when the power went out. When the power came back and I went to start everything back up, the BIOS saw the drive, but it never spun up and I was left with the 'operating system not found' message.
The drive was pretty old (Seagate 3.5 gig, I think) and there wasn't any really valuable data on it (or I would obviously have backed it up), but I wanted to at least boot the box one more time to see if there was anything I wanted to recover. I put the drive in a ziploc and stuck it in the freezer for like 20 minutes. Took it out, hooked it back up (leaving it in the bag to try to prevent as much condensation as possible), and it spun right up.
Turned out there wasn't anything of any real interest on the drive, and it refused to ever spin up again, but I can vouch for the fact that this does indeed seem plausible.
There is much cruelty in the universe, John.
Yeah, we seem to have the tour map.
Freezing will not help with a head crash or key sectors going bad. But there have been cases where it works. Back in the early 90's there was a problem with many Quantum-brand drives called "stiction", where the platter would not spin up after having been powered down. An internal lubricant (or adhesive, I forget which) basically got slightly runny when the drive got hot and re-solidified a bit out of place when cooled. This provided just enough friction to prevent the low-torque motor from being able to spin the drive up. Sometimes just rotating the drive quickly by snapping your wrist back and forth would do it. Freezing is another technique that worked (sometimes a combination of the two).
bp