Well, probably time to continue with another episode. This time with my "most beloved component", which is HDToolBox.
First, one bug I am responsible for: If you scan a SCSI chain, and there is a "hole" in the assigned IDs - e.g. SCSI IDs 0 and 1 are present, 2 is not, but 5 and 6 are - then HDToolBox stopped looking for any further drives once it found a non-existing ID. The story is that I was actually attempting to abort the loop for scanning for LUNs, logical units, but I hit the wrong loop. Oh well, this is fixed.
All other issues were old, from 3.1 times and before. The first newly discovered issue is how HDtoolbox "determines" the drive geometry, i.e .what you see as "sectors per block" "number of tracks" and so on. Nothing of that data is in good relation to reality, and most of the data is just "phantasy" the HDToolBox makes up. Background is that SCSI disks simply address disks as a linear list of sectors, and even if they have tracks, the track size varies by the cylinder, so the physical reality does not fit into the "rigid" scheme used by the dos.library for mounting disks. HDToolBox has just to make up a reasonable geometry such that the entire number of sectors fits, or is at least not larger than the real number of sectors.
Problem is, what is "reasonable". Well, if you had a disk initialized, HDToolBox reserved two tracks for the RDB to store the file system in. Always. Unfortunately, if the disk geometry is not reasonable, two tracks may be just "very little", e.g. if the algorithm generated a disk geometry (all made up, as said) with 2 sectors per track. Then there would be a total number of four sectors available for the RDB - where it does not fit in, of course.
So that got fixed, both the algorithm how the disk geometry is estimated, or made up, and second, the number of tracks to reserve for the RDB.
Then, we had a couple of issues where users put the FFS on a quite large (for Amiga times, at least) partition, and then received an "Out of memory" when attempting to validate the partition. This can be resolved by using a larger block size of 4096 bytes rather than 512 bytes, and the former is recommended for many modern drives and SD cards anyhow that work internally with 4K sectors. So HDToolBox now switches to 4K sectors when the partition size is large enough, and it also aligns partitions to 4K boundaries.
Finally, we have two "freak accidents" in the HDToolBox, errors that are real "face palm" experiences. No, this time not caused by me. First, the stack size of a file system. HDToolBox was kind enough to recognize that the FastFilesystem is not written in BCPL and hence does not require a "GlobVec", but it did not enter a stack size for it, so the stack size remained at its default, as created by the expansion.library when creating the mount list of the drive. The default is 600.
The right question is now "600 what"? And the answer is "it depends...". Unfortunately, the dos.library knows two types of handlers: BCPL handlers and C/assembly handlers. The former are created by an internal function named "createtask" (not to be confused with exec tasks) and it takes the stack size in long words. The latter are created by "CreateProc", which takes the stack size in bytes. So, if you mount a handler with "GlobVec=0", then the stack size in the mount list means "long words", and if it is a C mount, the stack size means "bytes". Unfortunately, the default left behind by the expansion library is "BCPL mount", which - with a stack size of 600 - results in 2400 bytes of stack. As soon as the HDToolBox patches this to "this is a C mount", the result is a stack size of 600 *bytes*, which is really quite tight, even for the FFS.
So, in the end, HDToolBox now also leaves sufficient information to extend the stack size to 2048 bytes.
The second accident is in the bytes/block settings for the fast file system. Betatesters reported that whenever a file sytem was removed from the RDB, the block size was reset to 512 bytes, which then resulted in an unsuable partition if the partition was originally formatted with larger block sizes. This sounds like a (well not harmless but) simple GUI bug, but it wasn't. To understand the issue, you need to know how partitions are mounted.
Step 1) is that the expansion.library creates a "template" for the mount list (or its equivalent), which is "globvec = 0" (BCPL mount), 600 LONGs stack (see above), 1 sector per block.
Step 2) is that the firmware of the hostadapter uses this template and fills in the partition boundaries from the disk, such as "LowCyl" and "HighCyl".
Step 3) is that the file system is loaded from RDB and has a couple of ideas of its own what it needs, so for example to get the GlobVec and the stack size replaced. This is communicated by "PatchFlags" which instruct the firmware to replace some of the entries created in 1) or 2) by data by its own.
Now, if you instruct HDToolBox to use a different number of sectors per block, two things happen: First, the partition layout is modified, that is, the data in step 2). Second - and this is the crazy part - HDToolBox also updates the Patchflags for the file system with something that looks "apparently" as if the block size is also to be modifed at file system level. (1<<DE_SECTORSPERBLOCK) is or'd into the patch flags.
This, however, would be fatal: A file system with the sectors per block patched over would mean that the sectors per block from the partiion is replaced. So if you create two partitions, one with 512 byte blocks, and another with 4096 bytes per block, and use one file system for both of them, the above patch flags seem to override the block size for both - and then ruins at least one of the partition.
Luckely (ehem) another bug compensates the first bug: (1 << DE_SECTORSPERBLOCK) is actually the wrong flag (face palm #2). Due to the way how the patch flags are enumerated, it modifes the stack size. Harmless for the partition, but leaves the stack size then at 0. Ok, the dos.library is not quite as stupid to allow this size, and then selects one by itself.
What is left is a typical exercise in database management: If you have two data entries that mean the same (block size at partition level, block size at file system level), you need to keep them consistent. HDToolBox attempted to do so, but failed. Whenver a file system was deleted, one part of the information was removed, and then the other - at partition level - was removed as well, resulting in an invalid block size at partition level.
So, two bugs, with only one of them the result might be more fatal than with two of them, but bad enough...
Needless to say, this was fixed. HDToolBox no longer attempts to (wrongly) set the block size at file system level, and now the block size stays where it should be if you remove a file system from the list.