Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site cithep.UucP
Path: utzoo!watmath!clyde!cbosgd!cbdkc1!desoto!packard!ihnp1!ihnp4!qantel!hplabs!sdcrdcf!trwrb!trwrba!escher!cithep!tim
From: tim@cithep.UucP (Tim Smith )
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases (absurdly long)
Message-ID: <94@cithep.UucP>
Date: Sat, 27-Jul-85 23:17:16 EDT
Article-I.D.: cithep.94
Posted: Sat Jul 27 23:17:16 1985
Date-Received: Fri, 2-Aug-85 02:30:33 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>, <5819@utzoo.UUCP>
Organization: Caltech HEP, Pasadena, CA
Lines: 12
Xref: watmath net.micro.att:363 net.unix-wizards:14132

I disagree with your statement that fsdb is not really needed because of
fsck.  There are problems that fsck refuses to deal with, for example,
an unallocated root inode.  Fsdb is very handy in this case.  Also,
possible file size errors are reported by fsck, but nothing is done with
them.  Fsdb is very useful here.  You can look at the inode, figure out
what the size should be ( actually, I have a program to do this part... ),
and set the size in the inode.  And how about trashed superblocks?
Also, I have noticed that if an ordinary file overwrites a directory,
fsck tends to core dump on that filesystem.
-- 
					Tim Smith
				ihnp4!{wlbr!callan,cithep}!tim