Thanks again for lots of interesting and useful details.
1. I understand your discomfort, but please relax and rest insured that:
- my philosophy is to take sole responsibility for whatever I do
- I never start risky actions without having a recent clone of my drive.
2. Did PowerQuest/Symantec develop this partinfo.exe? If so, then it's a
part of the PM installation and I used its W98 version a week ago, but it
didn't report any problems
You mentioned changing the boot indicator (00 or 80). Why not just
leave both your primary partitions as type 0x0C and change the boot
indicator when you want to change from XP to 98 or vice versa ?
3. If I understand properly, Win98 doesn't tolerate another primary active
partition on the system*. What's more, if you have PM installed, then it
takes care of sticking to the rules for you, so I can't do much about it. It
will change what it finds necessary. I know that my approach with switching
to another system isn't perfect, but I can deal with it.
Expanding your E: volume could have been a major task for PM. E: was
just under 8GB which means it could have 4kB clusters. When you
increase it to over about 8.3GB the cluster size has to be increased or
the cluster count will be too high for utilities such as DeFrag. How PM
can do this safely is beyond me.
4. While creating a new partition (here E
, PM asks you about the size of
the clusters to be used and I chose 8kB. By the way:
- only my WinXP partition uses 16kB clusters and the other partitions use
8kB clusters.
- As far, as I understand, 4kB cluster you mentioned is the MS default size
for partitions up to 8GB, but you can still use bigger clusters. Am I right?
Originally, I thought, it was only a slack problem.
5. The problem we are trying to resolve occurred when I extended WinXP
partition (with 16kB clusters) to 35 GB (over 32 GB). However, I didn't see
any problems with WinXP, but only with my partition D: (under Win98se). I do
hope that the cluster size wasn't a culprit in this case, although it should
increase to 32 kB.
Now, I will try to read more about the problem and perform some tests. Soon,
I will also resize WinXP partition as before, which can make my D:
inaccessible.
Regards,
Andrew
PS *A few quotations from the PM manual
If your hard disk has more than one primary partition, only one is visible
by default. When you use the Set Active operation, PartitionMagic unhides the
selected primary partition and hides other primary partitions.
If you are running Windows NT/2000/XP, partitions are not hidden
automatically; therefore, you can have multiple visible primary partitions.
Only one partition on a hard disk can be active at a time.
"Steven Saunderson" wrote:
On Sun, 30 May 2010 16:23:01 -0700, Andrew
wrote:
Thanks a lot for your interesting comments and helpful ideas.
I'm sorry to bother you again with my questions, hopefully last time, but
this might lead to a breakthrough.
It's not a bother but I'm sure you will be rather irked if your system
gets trashed due to my suggestions. If you want to see the details of
your disk layout can you download and run PartInfo.exe. It is a DOS
program and you can redirect the output to a file (e.g. "partinfo
my.lst").
You mentioned changing the boot indicator (00 or 80). Why not just
leave both your primary partitions as type 0x0C and change the boot
indicator when you want to change from XP to 98 or vice versa ? This is
how I do it and the only complication in your case would be if PM has
changed your MBR code. This is unlikely but I honestly don't know.
To resize my WinXP(* partition located in the following sequence of
partitions: [C: Win98, (* WinXP, D:, E:, Unallocated] by 7GB, PM had to go
through 5 'elementary' steps in the order displayed below:
a. Resize Extended (* by 7GB (taken from Unallocated)
b. Move E: up by 7GB
c. Move D: up by 7GB
d. Resize Extended (* down by 7GB
e. Resize WinXP (* by 7GB
The overlapping copies in steps b and c could be risky but I'm sure that
PM is doing them carefully so there is no data loss if a crash (e.g.
power loss) occurs. Step d sounds a bit risky because the LBA keys in
the EPBRs are relative to the extended partition. Step d would involve
changing each EPBR and then updating the MBR and I'm not sure how PM
could recover from a crash in this short step.
Are these details somehow useful for confirmation of your idea about these
strange values?
An authoritative reference for FAT32 is an MS document called
FATGEN103.PDF which should be easy to find. "Hidden sectors" is
generally the offset of the volume from the sector containing its
partition entry. So, for primary partitions it is the absolute key and
for logical partitions it is 63. But, I've seen exceptions and the
volumes are still accessible so maybe the value isn't used.
You mentioned a high "first cluster of root" after you'd resized E:.
This suggests that PM has created new directory records and switched
over to these lists once the data copying was complete.
Expanding your E: volume could have been a major task for PM. E: was
just under 8GB which means it could have 4kB clusters. When you
increase it to over about 8.3GB the cluster size has to be increased or
the cluster count will be too high for utilities such as DeFrag. How PM
can do this safely is beyond me.
I still haven't answered your question about D: being inaccessible in
Win98. Can you setup your disk so D: is inaccessible and then run
PartInfo to get the list ? One other source of info here is the MSFN
forums (search for Win98 IO.SYS).
Cheers,
--
Steven
.