[Coco] 248 errors in NitrOS-9 repository

[Tormod Volden]

On Sun, Jul 21, 2013 at 4:53 AM, Robert Gault  wrote:
> Lothan wrote:
>>
>> I'm leaning toward it being a bug in os9.exe. The reason I say this is
>> because
>> the output of make for the sierra christmas86_dw.dsk, I see error 248
>> adding a
>> few files to the root directory of this disk. The odd thing is that this
>> disk
>> has 2MB or more free and the root directory only has 8 files in it. I also
>> checked the segment entries for the root directory and found the root
>> directory
>> has 8 sectors allocated to it. Strange.
>
>
> Well here is a clue.
> test disk kyumgai.dsk
>
> after compiling with many 248 errors:
>
> os9 free kyumgai.dsk
>
> "Kyum-Gai: To Be Ninja" created on 07/20/2013
> Capacity: 360KB (1440 sectors) 1-sector clusters
> 1130 Free sectors, largest block 1130 sectors
> Free space: 282KB (289280 bytes)
>
> from NitrOS-9 on kyumgai.dsk in drive0:
>
> free /d0
>
> "Kyum-Gai: To Be Ninja" created on: 2013/07/20
> Capacity: 1,440 sectors (1-sector clusters)
> 1,130 free sectors, largest block 932 sectors
>
> Note that while the total number of free sectors is reported the same, the
> report for largest block count is different. I've checked the count myself
> and 932 is correct. Os9.exe is miscalculating the largest free block.
> If os9.exe thinks a sector is free, tries a copy, and finds the sector full,
> that might be the cause of the 248 error.

This was a tricky one, especially since it was intermittent. I never
saw this error on Linux, and not on Windows/MingW either. However,
today I was able to reproduce it on MingW, so I did it the painful,
systematic way: First I built up the disk images step by step on both
Windows and Linux so that I could establish that a disk image built on
either would fail on "os9 copy" (the one with the many files) on
Windows only. Then I stepped through the copy routines on both
platforms and saw that at one point the disk image was recognized as a
DECB disk on Windows and as the expected OS9 disk on Linux. It boiled
down to a classic porting-to-Windows issue: Windows has the concept of
text versus binary files, where on the former linefeed translations
and end-of-file (ctrl-Z?) characters can come into play. Maybe a time
stamp containing a ctrl-Z caused a premature end-of-file when reading
in the sectors from the disk image.

I have fixed this in toolshed hg, and also updated the Windows binary
snapshots at http://toolshed.sourceforge.net/snapshots/

Tormod