Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: fsck's & lost+found directory question
Message-ID: <17256@mimsy.UUCP>
Date: 3 May 89 08:25:36 GMT
References: <359@toro.UUCP>
Distribution: usa
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 21

In article <359@toro.UUCP> nick@toro.UUCP (Nicholas Jacobs) writes:
>... we discovered that the lost+found directory must exist in each
>file system. ... I was wondering if this is the case with all ports of
>SysV (and/or BSD)?  Does this mean that fsck goes into the device file
>and tries to find the actual directory (I would assume yes...)?

Most versions of fsck require not only that the lost+found directory
exist, but also that it contain sufficient slots to allow any `lost'
files to be reattached without having to allocate new blocks.

The 4.3BSD fsck (and therefore any based upon it, such as the one in
4.3-tahoe) has the ability to create a new directory and allocate new
blocks.  I still feel more comfortable having the directory already
exist---after all, files being reattached indicate that *some*thing is
wrong.  It may be something trivial, such as an open but unlinked file
in use when the power went out; but it may be that the free block map
is completely scrambled, and who knows what further havoc fsck might
wreak?
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris