#39 decb destroys disk images by inconsistent handling of image sizes

[Mathieu BOUCHARD]

Toolshed 2.2 decb has destroyed many of my disk images before I could realise it. If I have a collection of 256 disk images as one file, it can correctly read files from :240 and :241, for example, meaning that it correctly assumes disk size = 161280 in this case, but it can create files with granule numbers above 67 in the directory and in the granule table, as if the disk image had many more tracks, and so if I copy a file "to" image :240, it overwrites some file contents in :241 and causes image :240 to trigger ?IO ERROR when LOAD/LOADM is used, both with real diskettes (copied back using HDBDOS BACKUP 240 TO 0 or not) and emulator (with -flop1 on single image extracted using linux command dd bs=161280 skip=240 count=1). The use of granule numbers above 67 also cause Toolshed decb and HDBDOS DIR (or DECB.ROM's DIR) to report different sizes of files (e.g. 8 granules vs 2 granules, or 2 granules vs 1 granule, probably meaning that the latter stops counting granules at the first invalid one, except if the first invalid is the first granule of the file).

[Mathieu BOUCHARD]

Ok, more precisely, Toolshed seems to be confused by some non-conforming granule table sectors, that are padded with $FF instead of $00. In that case, it reports all those $FF as free granules when doing "decb free", therefore up to 256 free granules. HDBDOS and/or DECB ROM disagree about what it means. I did "decb dskini -h2 test.dsk" and then put $FF in the rest of the granule table sector, I used "decb copy" to put lots of files in that disk image and it overwrote so much of the 2nd disk image (blank) that "decb dir test.dsk,:1" displays garbage and freezes. Beyond a certain point, copying files to drive 0 will begin writing to an imaginary drive 2 past the end of file. E.g. instead of being 322560 bytes, my test.dsk is now 370944 bytes.

I don't know why any disks have this non-conforming padding. Not only I found it on some personal diskettes (last formatted 30 years ago), I also found it on the Cocomax2 original disk, which is permanently write-protected (no hole) as so was made as-is by Colorware, and is not a disk with non-DECB FS elements on it (not meant to be read by direct sector reads such as DSKI$), it seems to be a conforming FS except for the $FF padding of track 17 sector 2. I copied those disks using HDBDOS BACKUP to DriveWire4 and that's how I got such images in my 256-drive DSK file.

[Tormod Volden]

Hi Mathieu,

Can you suggest some solution to this? Can you modify the code to also check for $FF when counting free granules?

Independenly, it would be good if there was some bounds checking, that any computed location doesn't go beyond the current disk image.

[Boisy Pitre]

Outside of the FAT, I can't think of any way 'decb' woud know the size of a Disk BASIC disk image. It could take a conservative approach and assume all disk images are 35 tracks, with an option to "force" it to respect 40 tracks (or even 80) for all operations.

[Tormod Volden]

As soon as you specify a non-zero disk drive number (HDB-DOS), the size is already assumed to be 161280 (see libdecb/libdecbopen.c:132). Maybe as soon as a HDB-DOS colon delimiter is in use, we should activate some bounds checks (in libdecb/libdecbseek.c?). This would only be a safe-guard, but not solve the root issue of $FF padded granule tables.

[Tormod Volden]

I have pushed some fixes for this. If there is a colon in the file path, it is assumed to be an HDBDOS virtual floppy array where each floppy is 35 tracks and limited to 68 granules. When searching for or counting free granules it will only scan through the first 68 entries in the granule table.

I stepped into the issue that ToolShed at least partly tries to support HDB-DOS hard drive images where only the lower 256 bytes of each 512-byte sector is accessed. However it doesn't seem consistent, for example with the decb dskini -h option which simply makes an array of "dense" images. In my last commit (755) I left it with this scheme: If an HDB-DOS offset is specified (with the + delimiter) it will include the "wasted" sectors, and if not (just the : delimiter and a drive number) it will assume "dense" images. This might need more work, probably another internal flag and possibly new command line options to deal with both cases.

[Tormod Volden]

Mathieu, would it be possible for you to test this, or send me such a disk image (ideally the Cocomax2)?

[Mathieu BOUCHARD]

Sorry, I haven't used decb nor drivewire nor the CoCo since Sep 2018. But the Cocomax2 disk image has been all along in https://colorcomputerarchive.com/repo/Disks/Applications/Coco%20Max%20II%20%28Colorware%29.zip , and I just ran «od -Ax -tx1 "Coco Max II (Original).dsk"» and at position $13300 (FAT8 table) it shows FF padding.

[Tormod Volden]

Thanks! I downloaded the image and concatenated the three disk in to one "HDB-DOS" image called cocomax.img

When I run the old toolshed 2.2 decb:

$ decb free cocomax.img,:2
Free granules: 193 (444672 bytes)

And with the current repo decb:

decb free cocomax.img,:2
Free granules: 5 (11520 bytes)

(It took me some time to realize how important that comma is...)
So that seems to work well for "dcb free" at at least.

Of course, this also works for a single disk image if treated as a "HDB-DOS" image:

decb free 'Coco Max II (Original).dsk,:0'
Free granules: 5 (11520 bytes)

I would like to also verify this with a "decb copy" scenario as yours, but haven't gotten there yet.