[This may be a duplicate message.  My Fido host had a glitch]
[that prevented mail from going out for an unspecified      ]
[length of time, so I have to repost recent messages.       ]


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