"134 UNIX System Administration Handbook
...
The lost+found directory is automatically created when you build a filesystem. It is
used by fsck in emergencies; do not delete it. The lost+found directory has some
extra space prealocated so that fsck can store "unlinked" files there without having
to allocate additional directory entries on an unstable filesystem. Some systems pro-
vide mklost+found command that can recreate this special directory if it is aci-
dentally deleted.
...
" "52 UNIX FOR SUPER-USERS
...
The filestore consistency check is performed by the command fsck (usu-
ally stored as /etc/fsck, but sometimes in /bin), which should be used to check
all discs used as file-systems. It defaults to the list of filestore devices given
in the file /etc/checklist. At this stage, most of the file-systems will not be
mounted, so will be inactive; only the root file-system will be active. The
fsck command goes through each one in turn, reports any inconsistencies in
them, and offers to correct them. The reply to each query is either 'y' for yes
(correct the inconsistency), or 'n' for no (leave the file-system inconsistent).
A parameter '-y' to the command assumes 'yes' replies to all questions, so
that no further interaction is necessary; a parameter '-n' similarly assumes
all 'no' answers, and therefore needs no write permission to the device. Any
'yes' reply may involve the loss of information, such as the complete removal
of a suspect file. Suspect files on the file-system being checked are written to
a directory lost + found on the device if such a directory exists; this directory
must have been created, and be sufficiently large already to hold the names
of all the files involved. This can be ensured by first creating the directory,
then creating a number of files in the directory, and then removing them.
The corrected systems will be consistent, and can later be mounted as and
when required. It may be possible to recover information from deleted files
by looking at the lost + found directory. There should be a lost + found direc-
tory at the head of each mountable file-system.
When checking the root file-system, there are complications, in that it
will be active (even though, because it is root, it will not be formally mounted
as such, but is implicitly mounted as root during the booting process). If
modifications are necessary, they should be completed, and the machine
rebooted without first performing a sync (see section 4.5 below for the nor-
mal procedure for taking a system down). This is to ensure that the disc as
modified by fsck is not overwritten by any in-core information, which may
have been generated from information read from the original corrupt (incon-
sistent) version.
...
"
But I've also read more detailed explanation that recollect is that unless blocks were preallocated, there was a possibility that lost+found need first allocate more blocks directory it already had, it would possibly led to losing some data that would otherwise been able to recover once fsck had advanced further from that point.
Then few weeks after finishing book I ran into his LinkedIn post (bit OT sure) if what book told was his recollection still accurate in part where book refers his work at DEC Systems Research Center (SRC) at the time. Following is what he replied to me:
" markoff and hafner did extensive research and the book is accurate in all ways i could know. note that while mitnick has paid his debt to society (jail time), i've never received from him an apologia. my only other written mention of those breakins was here:
https://www.linkedin.com/pulse/burdens-blame-paul-vixie/ "