Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The classic Unix horror story

lug.wsu.edu

Post reply on HN
Print view View original

41–50 of 54 posts

Re: The classic Unix horror story

#41

Post by enneff »

randrews wrote: post #22
naner wrote: post #20

Earlier quoted context omitted.

Writing this comment, I had to look up the order of the parameters to tar; I still can't remember. Stupid tar. The -f (--file) flag takes an argument. So you could do: tar -cf *.cpp -f something.tar It is easier to remember order if you know what the flags mean.

It's true, and I'll probably remember it now. But, since I have every single time used the -f flag, it would make a lot more sense for it to say "you asked me to compress a file that doesn't exist and ends in .tar; I bet that's what you meant the -f parameter to use" and fix it for me.

I'd rather not have my tools perform magical heuristics to try to figure out what I meant to do.

The "-f " flag is perfectly clear, and useful in all modes (c, x, etc). If you remember "tar czf" as a magical incantation, then you're missing something vital. When you understand what each argument means there is no ambiguity. I don't mean to sound condescending, but in my entire life I've never encountered the problem you described.

Re: The classic Unix horror story

#42

Post by enneff »

mkramlich wrote: post #16
randrews wrote: post #9

I've never actually been bitten by rm (or done anything remotely this badass) but in college I did have a bad Unix moment: Late at night, I was tarring up a finished project right before emailing it to my professor. I ran: tar -cvf *.cpp *.h something.tar instead of: tar -cvf something.tar *.cpp *.h It happily wrote most of my project into a tar file on top of the first source file, then complained that something.tar…

I think personal experiences with shell command typo disasters and hard drive failures are probably the most common, and most effective reasons why people start using version control and backups religiously. The Unix command-line in particular is dangerous: incredibly powerful when used right, but one slight mistake and you cut off a finger. Fortunately, they are only virtual fingers and we can grow them back on dema…

Version control is also fantastic because you can think a lot less about making drastic edits. Gone are the days when I would keep bits of code commented out "just in case" I needed it back at some point.

Re: The classic Unix horror story

#43

Post by dasil003 »

enneff wrote: post #42
mkramlich wrote: post #16

Earlier quoted context omitted.

I think personal experiences with shell command typo disasters and hard drive failures are probably the most common, and most effective reasons why people start using version control and backups religiously. The Unix command-line in particular is dangerous: incredibly powerful when used right, but one slight mistake and you cut off a finger. Fortunately, they are only virtual fingers and we can grow them back on dema…

Version control is also fantastic because you can think a lot less about making drastic edits. Gone are the days when I would keep bits of code commented out "just in case" I needed it back at some point.

Mostly, although I take issue with the "never leave commented code around, that's what version control is for" as an absolute. If it's something that is not adequately replaced, and is likely to save some time for someone in the future then it's better to keep it commented out rather than removing it since future devs may never know it even existed.

Re: The classic Unix horror story

#44

Post by djacobs »

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.

Re: The classic Unix horror story

#45

Post by nitrogen »

cdavid wrote: post #31
sketerpot wrote: post #5

Earlier quoted context omitted.

I was playing with FUSE, and had managed to mount a loopback filesystem. And then, for some ill-considered reason, I tried to delete the directory that I had mounted it inside. I managed to Ctrl-C it before it ate any files in /home, but I still had some nasty cleanup work to get the computer back in working order again. Thank god for LiveCDs.

In the same spirit, I once removed a chroot tree, forgetting I bind mounted /etc into it. It took me half a day to recover from that. Another one, even more stupid, is to recover a "backup" of /var, done without the proper rights to it. I noticed the problem after a lot of weirds errors cropping in. This one I did not recover - after a few hours, I ended up deciding that reinstalling linux on my machine would be fast…

I've found it's useful to look through the man pages of commonly-used tools for an option to prevent traversing filesystems.

Re: The classic Unix horror story

#46

Post by pilif »

This reminds me of the faithful day when I finally stopped working as root all the time.

That happened right after typing

    cp backup.tar.gz /dev/sda
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

Re: The classic Unix horror story

#47

Post by gradschool »

xyzzyz wrote: post #29

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 just do what we tell them to.

They have their uses. When the Unix user group at my college sent out invitations to a social event, they concluded with "... and if you don't want to come, log on to Unix and type rm -r *".

Re: The classic Unix horror story

#48

Post by anon_d »

randrews wrote: post #9

I've never actually been bitten by rm (or done anything remotely this badass) but in college I did have a bad Unix moment: Late at night, I was tarring up a finished project right before emailing it to my professor. I ran: tar -cvf *.cpp *.h something.tar instead of: tar -cvf something.tar *.cpp *.h It happily wrote most of my project into a tar file on top of the first source file, then complained that something.tar…

> Writing this comment, I had to look up the order of the parameters to tar; I still can't remember. Stupid tar

    ; tar c *.cpp *.h >something.tar
    ; tar c dir | gzip >something-else.tgz
Problem solved! Also:

    ; tar c dir | gzip | nc -q0 -lp 4000 &
    ; [another computer]
    ; nc $otherhost 4000 | gnuzip | tar x

Re: The classic Unix horror story

#49

Post by jodrellblank »

phugoid wrote: post #40

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". Salvaging the disk by recreating a minimalist system on it is heroic and hacky, but was that the only way?

When the story mentions "Alternatively, we could get the boot tape out and rebuild the root filesystem" and "VAX", then "a lot of Googling" was out of the question.

I'm too young for the VAX era, but was there "a" hard disk which could be easily swapped and if they had another (which the Ethernet comment suggests they did) then would it have spare connectors? and free disk space? How fast did files copy back then?

If so they'd still be faced with shutting both down (knowing they couldn't start this one up again, and what was the procedure for shutting down / starting the other?) then be without both while they concocted a bodge recovery, then be faced with telling everyone to use the other and how to find their work - assuming if could take that many extra users and they had enough terminals for that.

That's sounding like a day's downtime of two systems and several days of people disruption followed by more disruption when they had to move users back.

Re: The classic Unix horror story

#50

Post by jodrellblank »

djacobs wrote: post #44

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.

I'm going to guess, if they're in use you wont be allowed to delete them, and then you'd be in a similar situation - things like notepad would be missing, various programs wont start due to missing dependencies.

In fact, we can see from Youtube:

Ubuntu: http://www.youtube.com/watch?v=D4fzInlyYQo

Windows XP: http://www.youtube.com/watch?v=0aSo8-VDS8E

XP appears to hold up slightly better - it doesn't ruin the fonts, and it pops up a System File Protection dialog indicating it has noticed the broken system files and asking for an install CD to recover them from.

Post reply on HN