Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.unix.sysv386
Subject: Re: fsck Recovery From Crashes
Keywords: inode file directory lost+found
Message-ID: <1991Jun02.184143.15566@virtech.uucp>
Date: 2 Jun 91 18:41:43 GMT
Article-I.D.: virtech.1991Jun02.184143.15566
References: <35@metran.UUCP>
Organization: Virtual Technologies Inc.
Lines: 49

jay@metran.UUCP (Jay Ts) writes:

>1.  When the system is booting after a crash, and fsck runs and reports
>that it has cleared an inode, am I guaranteed that if it belonged to a
>"real" file, that the file will be placed in the lost+found directory?

If it clears an inode you get nothing in lost+found.  Only unattached
files/directories (ones that have no parent directory) get put into
lost+found.

>2.  When I run
>	cd lost+found
>	file * 
>file may report that some of the entries are "directories".  What does
>this mean?

This means that a directory was unattached.  You should be able to cd
to it and look around to see what is there.

>  If a file is "empty", does this mean that its contents were
>lost, or that it was empty before the crash (or is it undeterminable?).

Undetermined

>3.  Is it possible to *completely* recover a filesystem after a crash, when
>    fsck has modified the filesystem (other than when it simply sets its
>    state to "OK", that is)?  If so, how?

To be totally 100% safe you have to restore from backup.

>What prompts this query is that I keep running into new clients' UNIX
>systems that have been running for months or years with files in the
>lost+found directories on one or more filesystem partitions, with apparently
>no loss in functionality.  Is it ok to just let them go like that?

the reason for this is that the most likely files to be placed into
lost+found are files that are modified by users.  OS files/programs
are much less likely to be modified and therefore not likely to 
be thrown into lost+found.   I never restore from a backup just because
I end up FSCKing a filesystem.

>Opinions accepted, but please document them as such!

All this stuff is opinions.

-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170