[Coco] NitrOS-9 dcheck and hard disks

[Gene Heskett]

On Thursday 25 September 2008, Chuck Youse wrote:
>On Thu, 2008-09-25 at 20:00 -0400, Gene Heskett wrote:
>> On Thursday 25 September 2008, Chuck Youse wrote:
>> >So dcheck doesn't like my 500-700MB disks.  I run dcheck and it likes to
>> >crap out with messages like "segment out of range" on disks that I am
>> >99% certain are perfectly clean (like, I just formatted them and copied
>> >a few files over).  Is this not the right tool for large disks?  Am I
>> >running across a bug?  Am I doing something wrong?
>> >
>> >C.
>>
>> ISTR I ran into something similar with the 3.2.7 version of dcheck. 
>> Robert Gould then did some looking, as did I, and the upshot was Robert
>> adjusted a thing or two, which may or may not be in the 3.2.8 version of
>> Nitros9, but it should be in a fresh cvs checkout.
>
>Hmm..
>
>cyouse at dev:~/src/nitros9/level1/cmds$ cvs status dcheck.asm
>===================================================================
>File: dcheck.asm       	Status: Up-to-date
>
>   Working revision:	1.9
>   Repository revision:
>1.9	/cvsroot/nitros9/nitros9/level1/cmds/dcheck.asm,v
>   Sticky Tag:		(none)
>   Sticky Date:		(none)
>   Sticky Options:	(none)
>
>It's the latest source.  What you were saying about cluster sizes makes
>perfect sense, I just thought this would have been long put to bed (I
>remember calling an Rottinger's RCIS system in the 90s, he had 300+ MB
>disks on his L2 system).
>
I wouldn't bet on it, check the size

root at coyote cmds]# ls -l dcheck.asm
-rw-r--r-- 1 Sparky5555 Sparky5555 85553 2008-06-19 11:16 dcheck.asm
And
-rw-r--r-- 1 root       root          9855 2008-07-05 04:48 /opt/nitros9/level1/coco/cmds/dcheck

And I see my notes in the header didn't reflect what Robert Gould may have done.

Much of the shrinkage shown above was me going through it getting rid of the
universal use of LBSR when the jump was within BSR range.  There was a huge
pile of them.

I don't have that particular error anymore, but I believe if there is an
allocation error, it is not being reported exactly correctly just yet.
It did give me enough info to patch my fat and eliminate the pair of errors
I actually had though.  Sort of an off by one error, I think.

Robert?  Hello?  Is the above the latest?
>Maybe Robert Gault will pipe up on this issue within a few days, if not,
>I'll see if I can track down the problem in dcheck.asm.  The good news
>(for the moment) is that it's not some sort of phantom read/write
>problem in my HDISK driver.
>
>C.
>
>
>
>--
>Coco mailing list
>Coco at maltedmedia.com
>http://five.pairlist.net/mailman/listinfo/coco



-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Is that really YOU that is reading this?