Daniel Carosone <dan@anarres.mame.mu.oz.au> wrote:

> I don't think I've ever seen it place files in lost+found (though II
> could of course have missed or fogotten a case or two). I *know* that
> I have seen it many times find "unreferenced files" with non-zero
> size, and it's cleared them instead of reconnected them.

If the inode is valid, i.e. the file is OK, but it doesn't appear in any
directory, then it gets placed in lost+found. If the file is zero length,
it just gets zapped. Most damage to the inode results in deletion as well.

Try creating a directory, putting a few files in it, then unlink(2) the
directory. It'll work in current :-) and it gives you a nice glimpse of
what fsck can do. I've seen it happen in practice on an old PDP-11 with
Unix V7 (and no reliable media to reload the OS from). It's fun to have a
lost+found full of unknown files and sorting them out... Hmmm... looks like
a Makefile...

Most corruption I see is due to bad SCSI termination or cabling. The
results are usually zapped inodes (zeroed out completely). This will result
in inodes being cleared in one phase, and directory entries getting removed
in a later phase of fsck. Since all information on which disk blocks
constitute a file is lost, fsck can't be of any assistance recovering here.

All in all, if fsck can't fix it, I trust fsck to have done its best, and
my next action is a newfs. By the way, I always enjoy running fsck on SunOS
machines which support the clean bit (4.1.3 and higher, if I remember
right), if they're about a year old. It's a good exercise in what all those
fsck messages mean, and it impresses da girls big time (da boys as well,
but I don't care).

I'm sorry, it's tuesday morning over here...

                                        -- Bert Driehuis

------
Bert Driehuis                 God, grant me the serenity to accept the things
driehuis@playbeing.org        I can't change, courage to change the things I
                              can, and the wisdom to know the difference.