Some senseless babbling from Jonathan De Boyne Pollard to Mike Ruskai
on 11-04-99  22:49 about Multiple primary HPFS...

 MR> If a person has more than one primary partition on the one drive, all
 MR> of which are formatted HPFS (OS/2, and an OS/2 maintenance partition,
 MR> perhaps), then I'll be finding several candidate partitions.
 MR>
 MR> Is there a simple way to figure out which one is correct?  Perhaps
 MR> there's a value for the partition status indicating whether the
 MR> partition is accessible or not?

 JDBP> Partitions are "hidden" by programs such as Boot Manager by changing
 JDBP> their types to an "unrecognised" type.  Usually this is done by just
 JDBP> flipping a bit or two in the type byte.  So the answer is that if you
 JDBP> have "hidden" partitions they will usually have types that, as
 JDBP> standard, operating systems will not recognise as valid partition
 JDBP> types.  There will be only one primary partition in the primary MBR
 JDBP> that has a valid partition type (and that isn't an extended partition),
 JDBP> and that will be your candidate partition. 
 JDBP> The reason that it works this way is because of the way that most
 JDBP> operating systems look for partitions when assigning drive letters to
 JDBP> them.  They use a very simplistic algorithm.  They stop processing the
 JDBP> table in each MBR when they reach the first (non-0x05/0x0F) partition
 JDBP> with a type that they recognise. ( If you want to see how OS/2 does
 JDBP> it, look at the code for OS2DASD.DMD on the OS/2 DDK, and look at the
 JDBP> Process_Partition function in the file DMBPB.C . ) 
 JDBP> The slight exception to this rule is Windows NT 4.0, which caters for
 JDBP> more than one primary partition having a recognised type in the primary
 JDBP> MBR.  This allows for up to four primary partitions per disk.  But as
 JDBP> the prominent warning displayed by Windows NT's Disk Manager utility
 JDBP> when one tries to create more than one primary partition explains, this
 JDBP> is incompatible with other operating systems.  (Well, *most* other
 JDBP> operating systems.  (-:) 

I wish Fido were faster :)

I had since already come to that conclusion, by managing to create two
primary partitions on another machine, formatted HPFS.  OS/2 sets the type
to 0x17 when hidden, so the one and only 0x07 in the partition table must
be the correct one, whether or not the volume in question is a primary
partition or a logical drive in the extended partition.

 JDBP> I thought that you had already solved this problem, though.  Didn't
 JDBP> you say that the DosDevIOCtl to obtain the BPB gave you in the
 JDBP> "reserved sectors" field the offset from the start of the "drive" to
 JDBP> the partition ?  Surely that solves this very problem ?

Actually, I was referring to the "hidden sectors" field.  As I implemented
it, it did not work.  I was just adding that value to the sector number of
the TrackTable[] entry.  If I used that value to get a proper CHS value, it
might work.

As it is, I've already done the partition table work.  I read in the first
sector of the "logical drive", and if it ends with 0x55AA, I consider bytes
446 through 509 to be the partition table.  From there, the first (and
necessarily only) type 0x07 partition found is what's desired.  Since the
CHS values aren't necessarily useful (consider a logical drive that's
entirely beyond the 1024th cylinder), I just use the boot sector location.
Add that to the LSN, convert to a CHS value, and DosDevIOCtl() gets what
it's supposed to.  It works on every type of partition I have (I tested
finding FAT drives, too).

I've put all the functions I've been playing around with into a single
program now, which will set the HPFS dirty bit, report the free space
discrepancy, report the total system usage, and dump any sector on the
drive.  Once I think of a few more pseudo-useful things to do, I'll put it
up for download.

Then I might try playing around with a HPFS undelete program, which brings
me to a question about something you mentioned previously.

It does stand to reason that any FNode which resides in a sector marked
free is a deleted file, that could potentially be recovered.  What about
FNodes that happen to reside in the reserved but as-yet unused sectors of a
file?  That is, when a file is created with some slack space to grow into,
it's slack space will be marked used, but not written to yet.  Could there
not be an FNode, or even file data, in that slack space which can be
recovered?

Mike Ruskai
thannymeister@yahoo.com


... Arguing logic with a programmer can get you hexed.

___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/Wildcat5! v3.0pr2
396/1