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.
I don't know about that article being funny, but I knew a guy in colleg who woke up to a random dude pissing in his keyboard. I'm not sure if the keyboard was ruined, but I do know that it was trashed (much like the random dude). Cops were involved and the guy ended up having to buy a whole new system for my friend. So if you're in college and you're not locking your dorm room door, you might want to put a towel or something over your keyboard at night.
Mark A. McBride -- OmniNerd.com
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 tried freezing a drive that wasn't working once. Didn't help any.
What did help was taking the cover off and physically holding the arm in place so the head couldn't jump back and forth. Drive worked well enough to get data off after that.
It should be noted that this solution was simply a result of getting really pissed off at the drive because nothing else would work.
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
I originally heard this story from Art during a lull in a seminar on programming implementation when he was a visiting professor at the UofU. It is the best story I ever heard for proving than no good deed goes unpunished. It is also, the funniest computer story I have ever heard.
Stonewolf
Read on....
Subject: Always Mount a Scratch Monkey
Date: Wednesday, 3 September 1986 16:46-EDT
From: "Art Evans"
To: Risks@CSL.SRI.COM
In another forum that I follow, one corespondent always adds the comment
Always Mount a Scratch Monkey
after his signature. In response to a request for explanation, he replied somewhat as follows. Since I'm reproducing without permission,
I have disguised a few things.
My friend Bud used to be the intercept man at a computer vendor for calls when an irate customer called. Seems one day Bud was sitting at his desk when the phone rang.
Bud: Hello. Voice: YOU KILLED MABEL!!
B: Excuse me? V: YOU KILLED MABEL!!
This went on for a couple of minutes and Bud was getting nowhere, so he decided to alter his approach to the customer.
B: HOW DID I KILL MABEL? V: YOU PM'ED MY MACHINE!!
Well to avoid making a long story even longer, I will abbreviate what had happened. The customer was a Biologist at the University of Blah-de-blah, and he had one of our computers that controlled gas mixtures that Mabel (the monkey) breathed. Now Mabel was not your ordinary monkey. The University had spent years teaching Mabel to swim, and they were studying the effects that different gas mixtures had on her physiology. It turns out that the repair folks had just gotten a new Calibrated Power Supply (used to calibrate analog equipment), and at their first opportunity decided to calibrate the D/A converters in that computer. This changed some of the gas mixtures and poor Mabel was asphyxiated. Well Bud then called the branch manager for the repair folks:
Manager: Hello
B: This is Bud, I heard you did a PM at the University of
Blah-de-blah.
M: Yes, we really performed a complete PM. What can I do
for You?
B: Can You Swim?
The moral is, of course, that you should always mount a scratch monkey.
There are several morals here related to risks in use of computers. Examples include, "If it ain't broken, don't fix it." However, the cautious philosophical approach implied by "always mount a scratch monkey" says a lot that we should keep in mind.
Art Evans
Tartan Labs
Monday, 19-Oct-1987
Actually, though I'm sure you're correct in some cases about the cold helping with a malfunctioning temp. sensor in the drive - I think the freezer trick also sometimes just works because of defective IC chips on the controller board portion of the drive.
(Every IDE hard drive actually has the drive controller electronics bolted to a circuit board on the bottom of it. That's why the "IDE interface" is such a basic thing on your PC, whether it's integrated onto the motherboard or is a seperate PCI card. Most of the real work is done on the drive's electronics.)
With some malfunctioning electronics, you can manage to keep them working properly as long as you keep them cold enough. (One of the old tricks for troubleshooting bad parts in TV sets and the like was to selectively spray them with a can of compressed air, chilling them temporarily.)