Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ll-xn!oberon!bbn!rochester!ur-tut!ur-valhalla!moscom!jgp
From: jgp@moscom.UUCP (Jim Prescott)
Newsgroups: comp.unix.wizards
Subject: Re: Down in the Dumps (a true story)
Summary: fsck can also kill filesystems
Keywords: dump, massive destruction, fsck
Message-ID: <1178@moscom.UUCP>
Date: 10 Jun 88 02:59:51 GMT
References: <406@thirdi.UUCP>
Reply-To: jgp@moscom.UUCP (Jim Prescott)
Organization: Moscom Corp., E. Rochester, NY
Lines: 30

In article <406@thirdi.UUCP> peter@thirdi.UUCP (Peter Rowell) writes:
>...
>In case you haven't already figured it out, the command in
>question (dump 0usf /dev/rmt0 /dev/rrf0g) will wipe out the
>file system residing on device /dev/rrf0g! (Yes, it really did...)
>...
>I *know* that being root is dangerous.  I just never expected that
>I could *create* a dead file system by using dump!

Nor did I expect to wipe out our file system with fsck (in preparation for
a dump 0 no less).  On our pdp11 running V7 I typed:
	fsck -c -t/tmp/foo /dev/re
and wondered why it started checking /dev/rusr.  Turns out that the the
temp filename MUST be a separate argument.  It ignored the /tmp/foo and
used /dev/re for its tempfile while it checked things out of /etc/checklist.
Fortunately it didn't overwrite any data, just the superblock and the first
167 blocks of inodes :-(

I just tried the same on a 3b2 and it seems that a check for the type of
the tempfile got added somewhere along the line.  Seems reasonable that
programs that expect files systems as arguments do a little more sanity
checking of arguments than normal.

At least we had backups.  (Actually the only backups were dumps done on
live (but quiescent) filesystems.  I had been unsuccessfull in convincing
anybody that at least doing the dump 0's on unmounted filesystems was
worthwhile.  All 3 dumps loading ok without even any warning messages.
This didn't do much for my fight for clean dumps :-).
-- 
Jim Prescott	moscom!jgp@cs.rochester.edu
		{rutgers,ames,cmcl2}!rochester!moscom!jgp