Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!ut-sally!pyramid!nsc!daisy!wje
From: wje@daisy.UUCP (William J. Earl)
Newsgroups: net.bugs.4bsd,net.unix-wizards
Subject: Re: fsck problem
Message-ID: <139@daisy.UUCP>
Date: Fri, 17-Jan-86 13:12:37 EST
Article-I.D.: daisy.139
Posted: Fri Jan 17 13:12:37 1986
Date-Received: Sun, 19-Jan-86 05:37:59 EST
References: <943@mit-eddie.UUCP> <860@bu-cs.UUCP>
Reply-To: wje@daisy.UUCP (William J. Earl)
Organization: Daisy Systems Corp., Mountain View, Ca
Lines: 30
Xref: watmath net.bugs.4bsd:1935 net.unix-wizards:16450

>>Re: fsck reports corrupted directory, asks to SALVAGE and then exits
>>on any answer.
>
>I believe I have seen this behavior, rather than attempt to fix fsck
>for you the following *might* work, but the risk is yours...
>
> ...
>
>(P.P.S. Glancing at that area of fsck.c there seem to be a few
>conditions which could cause this to happen, like a calculation in
>fsck_readdir yielding a zero (NULL) to dirscan and the filesize at
>that point appearing to be zero tho it's hard to check.)

    At our site, we fixed a bug in dirscan().  Just inside the for loop
which calls fsck_readdir(), we added:

	if (dp->d_reclen > DIRBLKSIZ) /* force it to be <= DIRBLKSIZ */
		dp->d_reclen = DIRBLKSIZ;

(This is added just before the statement "dsize = dp->d_reclen;".)
Without the check, fsck failed when it encountered a corrupted
directory block, even though it recognized it as corrupted,
as it tried to salvage directory entries.  We did not have
time to work on it further, but there are probably other such 
cases where certain kinds of garbage cause fsck to fail, due to
it not being suspicious enough.

-- 
	William J. Earl
	Daisy Systems Corporation, Mountain View, CA