fsck's & lost+found directory question

[Robert C. White Jr.]

in article <359 at toro.UUCP>, nick at toro.UUCP (Nicholas Jacobs) says:
> Since this was not documented under fsck (NCR's documentation comes
> from AT&T), 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...)?

As far as i know it is true of every (current?) flavor of SysV and/or
BSD Unix Systems.  The root directory of the file system being searched
is searched for a file named "lost+found" and that inode is used as 
scratch space for the reconnection of inodes which have no refrences
in the directory higherarchy of that file system but have a link count
indicating that they should.

Since the relinked file is just that "relinked" into lost+found/inode#
and no copying or what-not is done, there is no way that fsck *could*
put the information onto another file system.

It is also true that the directory lost+found must be "slotted" to allow
the insertion of the entry without the allocation of any disk blocks
because fsck dosn't know at that point if the free chain is valid
or not.  slotting is the act of creating some number of files in
the directory equal-to or greater-than your expected need, and then
erasing them (leaving the approprate number of blocks allocated to the
now-empty directory).  how many slots you allocate is up to you.

as part of mkfs our system creates lost+found as a matter of course.

I sounds like your doccumentation has been edited, as ours spesifies all
this clearly in FSCK(1M) (our 3B2 doccumentation is also direct from
AT&T), improperly to whit: "The only restriction is that the directory
lost+found must exist in the root of the file system being checked
and must have empty slots in which the entries can be made"

Rob.