Path: utzoo!attcan!uunet!lll-winken!lll-ncis!helios.ee.lbl.gov!pasteur!ucbvax!tolerant.UUCP!uucp
From: uucp@tolerant.UUCP (UNIX-UNIX Cp)
Newsgroups: comp.unix.microport
Subject: Submission for comp-unix-microport
Message-ID: <8901071051.AA07686@handel.TOLERANT>
Date: 7 Jan 89 10:51:06 GMT
Sender: uuclerk@ucbvax.BERKELEY.EDU
Lines: 30

Path: tolerant!voder!apple!bloom-beacon!think!ames!mailrus!cornell!batcomputer!itsgw!steinmetz!uunet!uport!dougm
From: dougm@uport.UUCP (Doug Moran)
Newsgroups: comp.unix.microport
Subject: Re: How does Microport System V/AT handle bad blocks?
Message-ID: <291@uport.UUCP>
Date: 5 Jan 89 17:36:54 GMT
References: <460@tarpit.UUCP> <326@focsys.UUCP> <464@tarpit.UUCP> <2689@nuchat.UUCP> <211@trevan.UUCP>
Reply-To: dougm@uport.UUCP (Doug Moran)
Organization: Microport Systems, Scotts Valley, CA
Lines: 19

In article <211@trevan.UUCP> trevor@trevan.UUCP (trevor) writes:
>This must be the worst bug in Microports system and is worse than most
>viruses. Why didnt Microport warn us of this problem? If they knew
>about it I think it was totally negligent of them not to have told us.

In the Release Notes for Release 2.4 of System V/AT, on page R-21,
is the following:

"File systems greater than approx. 130000 blocks experience corruption
over time that fsck can't repair.  fsck may report negative numbers
and corrupt the file system further (#605)."

There *is* a bug in fsck, we *are* aware of it, and we *are*
trying to fix it.  And we did try and warn you.  How can we
we warn you better (no sarcasm intended; I am trying to make
the Release Notes etc. more user-friendly)?

Doug Moran,
Tech. Pubs.