Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site sdcsvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!ittatc!dcdwest!sdcsvax!allyn
From: allyn@sdcsvax.UUCP (Allyn Fratkin)
Newsgroups: net.micro,net.micro.att,net.micro.pc
Subject: Re: Notes on the UNIX-PC
Message-ID: <1392@sdcsvax.UUCP>
Date: Sat, 8-Feb-86 12:17:51 EST
Article-I.D.: sdcsvax.1392
Posted: Sat Feb  8 12:17:51 1986
Date-Received: Tue, 11-Feb-86 05:43:59 EST
References: <1709@ihuxl.UUCP>
Organization: U.C. San Diego
Lines: 30
Xref: watmath net.micro:13747 net.micro.att:884 net.micro.pc:6884

In article <1709@ihuxl.UUCP>, stevet@ihuxl.UUCP (Turpin) writes:
> 
> Anyone who does not have this directory on their system should do:
> $ mkdir /lost+found

There is more to it than this.  Fsck will not allocate directory entries
(I guess it is worried about accdentally extending the size of lost+found
to the next block).  Anyway, you have to have empty slots already.
So you should also do this:
$ cd /lost+found
$ pwd	# verify cd worked.  disastrous results follow if cd failed
$ touch a1 2 3 4 5 6 7 8 99 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
$ rm *

This makes 30 empty slots in /lost+found available to fsck for file
recovery.

> If you have more than one filesystem on your hard disk you need to make the
> lost+found directory in the root of each filesystem.

You should do this entire procedure for the root of all mountable filesystems
(including floppies if you want them to be able to recover from some 
file system damage).

-- 
 From the virtual mind of Allyn Fratkin            allyn@sdcsvax.ucsd.edu    or
                          UCSD EMU/Pascal Project  {ucbvax, decvax, ihnp4}
                          U.C. San Diego                         !sdcsvax!allyn

 "Generally you don't see that kind of behavior in a major appliance."