Subject: Re: Minor bugs with AmigaDOS partition processing

From: William J. Coldwell <[email-masked]>

From: [email-masked] (Michael L. Hitch)

>Since a block number of 0xFFFFFFFF is out of range
>for any partition, the read of that block will fail and terminate the
>partition block processing - so the current code works like it's supposed to.

Generally, the RDB can be put anywhere within the RDB_LIMIT, which I believe is  
25 blocks (off of the top of my head).  Someone must have gotten confused  
between NULL and HB_NULL, which is the -1L as you have pointed out.  You can  
have a partition at block 0, and it would be perfectly legal to do so.

>The second bug is in computing the end of the partition.  The UPPERCYL field
>in the disk environment is the cylinder number of the last cylinder of the
>parition.

Since this is read-only, that doesn't seem to be so traumatic.  There is  
another set of cases where older partition programs didn't set the uppercyl  
field correctly, as in.. either being 0, or being -1, and a seperate case of  
loaders sticking stuff up on the RDB, like device drivers which autoboot ROMs  
load off.  In this case, there is very little need to parse the RDB all the way  
out to the end of the uppercyl.  So IMHO, the best way is to ignore uppercyl,  
and just read a block at a time, following the PART thread from the RDB.  I  
came to this conclusion after thinking that it would be fine just do an  
AllocMem() on the uppercyl-lowercyl values, then doing one read for the whole  
RDB.  We want the BSD boot to be as quick as possible ;-).