View Single Post
  #71  
Old June 2nd 10, 11:27 PM posted to microsoft.public.win98.disks.general
Steven Saunderson
External Usenet User
 
Posts: 37
Default Problem with accessing a partition

On Wed, 2 Jun 2010 04:30:01 -0700, Andrew
wrote:

1. My primary partitions are contiguous, which I checked, but I'm confused
about my logical partitions, esp. about the locations of EPBRs.


Vol. PartType Status PartSect # StartSect TotalSects

Ext.X Pri 0 2 93,675,015 39,776,940
EPBR Log None -- 93,675,015 24,177,825

D: FAT32 Log 93,675,015 0 93,675,078 24,177,762
EPBR Log 93,675,015 1 117,852,840 15,599,115

E: FAT32 Log 117,852,840 0 117,852,903 15,599,052

Everything looks fine. The extended partition starts at about 45GB and
is about 20GB (the first list line shows values from entry #2 in the
MBR; entries #0 and #1 will describe your primary partitions).

The second line is generated by PartInfo rather than showing part of any
disk record. I don't think the size of the first chunk of the chain is
explicitly recorded anywhere.

The third and fourth lines list the two entries in the first EPBR. This
is the start of the chain in the extended partition. The FAT32 line
shows that the D: volume starts 63 sectors later and is 24M sectors
long. The EPBR line shows that the next part of the chain starts at
sector 117M and is 15M sectors long.

The last line lists the next EPBR in the chain. This EPBR has only one
entry. The entry says the E: volume starts 63 sectors later and is 15M
sectors long. Because this is the end of the chain there is no "EPBR"
line which points along the chain.

"EPBR" in this list actually means a type 0x05 entry in a partition
table entry rather than Extended Partition Boot Record.

I note your comment about the PowerQuest patents. PM is probably more
sophisticated than most people realise. I don't know why it changes
your partitions from 0x0C back to 0x0B. Perhaps my understanding of the
codes is outdated or incorrect. But I still think that standard Win98se
(with IO.SYS dated 2001-12-01) should access the disk correctly if all
FAT32 volumes are type 0x0C. I've heard that IO.SYS regards type 0x0B
as type 0x0C if in the extended partition and this starts with 0x0F. If
this is true and the code that effects this re-interpretation is the
cause of your problem then setting the volumes to 0x0C should fix the
problem.

Cheers,
--
Steven