I have had this happen so often, I just have to post about
it.  After a crash or unexpected reboot, I have come up with files
that fsck insists on deleting --- even though I'm quite positve that I
havn't been writing to it any time recently.

	Here's the situation:  I'm compiling stuff on an NFS drive on
a local ethernet (with only two hosts).  The NFS host goes down.  Now,
for some reason, the compiling host gets wedged with NFS timeouts and
doesn't recover when the NFS server does (this may be due to the fact
that the server badly needs upgrading of it's userland).

	Anyways, when I finally reboot the client, it fails to fsck,
and a manual fsck insists on deleting /usr/bin/cc1 (or somesuch) and
/usr/libexec/uucpd.  Now... it's entirely possible that cc1 was
running.  Uucpd, however, was not even running.  Why would this
essentially unmodified filesystem fail fsck so badly on boot-up?

Dave.

-- 
----------------------------------------------------------------------------
|David Gilbert, PCI, Richmond Hill, Ontario.  | Two things can only be     |
|Mail:      dgilbert@jaywon.pci.on.ca         |  equal if and only if they |
|http://www.pci.on.ca/~dgilbert               |   are precisely opposite.  |
---------------------------------------------------------GLO----------------