Problem with accessing a partition
Andrew
this machine) is for a reason partitioned as follows:
C: (Win98se, primary, 14.5GB), * (WinXP, primary, 30.6GB), D: (logical,
11.8GB), E: (logical, 7.6 GB) and * (unallocated, primary, 87.5 GB).
All partitions are FAT32, created with the aid of Partition Magic (of Power
Quest).
Both OSs have been installed independently of each other.
I keep documents and photos on D: and some older backups on E:. Both
partitions are easily accesible for the active OS.
Yesterday, I tried to cross the 32GB limit (by 3GB) on the WinXP partition,
by resizing it (while in a hidden status). I did it with the aid of Partition
Magic 8.0 in Win 98se. After this resizing WinXP seemed to work OK and I
could easily access the files on the D: and E: partitions. However, I was
unable to access files on D: from Win98se - their names were scrumbled.
Strangely enough files on E: were accesible.
After resizing the WinXP partition down to the previous size, clicking on D:
issued a message of the type: “D:\ is not accessible, a system device doesn’t
work”. However, restarting Win98se returned everything to normal.
Do you have any idea about the reason of such a behavior?
Is there any chance to use bigger than 32 GB WinXP partition on my system
without compromising normal work of Win98se?
Thanks for your help,
Andrew
Hot-text
boot.ini, NTDETECT.COM, msdownld.tmp
VIDEOROM.BIN, + More
For the way you have it XP Boot is in win 98< For all the BOOT are in WIN98
you need C:\ for DOS LOOL!
D:\win98
E:\XP
F:\ so on, so on
"Andrew" <And...@discussions.microsoft.com> wrote in message
news:63F7C527-98D6-4ED3...@microsoft.com...
Hot-text
O by the way the only Drive you can make Bigger is the last Dive
If you make C:\ bigger it will take the Free Space from D:\
If you make D:\ bigger it will take the Free Space from E:\
If you make E:\ bigger it will take the Free Space from F:\
If you make F:\ bigger it will take the Free Space from G:\
If you make G:\ bigger it will take the Free Space from unallocated,
primary, 87.5 GB
you have to move the Space down form to unallocated
You can not give D:/ 3gb if all the Free Space from E:\ have is to you have
to Move Free Space Down!
OK
So Start over
"Hot-text" <hot-...@hotmail.com> wrote in message
news:79C39922-358B-4E20...@microsoft.com...
Hot-text
Move Free Space Down from unallocated!
First you need to Defragmentation All Drives
then Restart Computer
Move unallocated Space Down one Drive
Then Defragmentation That Drive
then Restart Computer
Move from that Drive some Free Space Down one Drive
Then Defragmentation The two Drives
then Restart Computer
Move from that Drive some Free Space Down one Drive
Then Defragmentation The three Drives
then Restart Computer
Move from that Drive some Free Space Down one Drive
Then Defragmentation The fore Drives
then Restart Computer
So on So On!!!
For that's the way to do it
Have Fun
"Hot-text" <hot-...@hotmail.com> wrote in message
news:2445BCBC-9483-4FA5...@microsoft.com...
Andrew
questions.
1. Are you really familiar with Partition Magic 8?
It does everyting nicely fand automatically for you, although it has to go
through several steps you are suggesting. It does this using its Wizard(s)
and you decide to some extent how to do it. I've been using it for quite a
time without any problems at all, even in the described by me configuration.
2. In order to make a partition bigger you have to have free space in the
adjacent partition, not necessarily the next one, as you are suggesting.
3. I don't need C: for DOS either
4. If you use D: for Win 98, then you can't have WinXP in E:, as this is
equivalent of having 2 active partitions at any time, which would only ask
for a disaster. I agree, however, that WinXP should be installed in the
partition following directly Win98, which is the case on my hard disk.
Hot-text
making a Partition!
You have to move the Free Space down from drive to drive Magic 8 can help
in the moving of the Free Space and
Have to Defragment as you go too!
our you will have Fragment it one Drive that go to the Fragment of the Drive
you made bigger!
and the drive will stop working!
Remember that why you here right!
"Andrew" <And...@discussions.microsoft.com> wrote in message
news:136F4DF8-0B32-4F20...@microsoft.com...
Andrew
your ideas are flat wrong.
The point is that you don't read my text carefully enough and consequently
you are not addressing my problems.
Most likely, this is also why you didn't notice that the drive I made bigger
worked perfectly OK before and after the resizing, which is in contradiction
to what you are claiming in this post.
Hot-text
Dive after it will stop working
Because you are moving Space form that Drive and making it smaller, Not from
the end of the Disk where the unallocated is for it will always be the same
Sizes! until you make the last drive partition bigger, or make a new
partition Drive! That why you move the bigger Down for.
You Defragment Because the Info on the Disk looks like this
01010101010 Free Space 01010101010 Free Space Free Space 01010101010 Free
Space 01010101010 Free Space Free Space
You to Defragment the move the info like this
01010101010010101010100101010101001010101010 Free Space Free Space Free
Space Free Space Free Space Free Space
That way you move the Free Space down not the info 01010
if you move the Info, that Drive it will stop working afterwards but the
bigger one Will worked perfectly
and if you Save a file in the bigger perfectly working afterwards you may
not be able to work that drive no more!
So that is the problems being address here right!
If project requires technicians to do service then call one.
They do for $35 to $45 a hour you look at a 3 to 6 hour job!
"Andrew" <And...@discussions.microsoft.com> wrote in message
news:B24CADAC-548E-4C00...@microsoft.com...
Steven Saunderson
<And...@discussions.microsoft.com> wrote:
> My 160GB Western Digital (48-bit LBA), PATA hard disk (the only HD I have on
> this machine) is for a reason partitioned as follows:
> C: (Win98se, primary, 14.5GB), * (WinXP, primary, 30.6GB), D: (logical,
> 11.8GB), E: (logical, 7.6 GB) and * (unallocated, primary, 87.5 GB).
> All partitions are FAT32, created with the aid of Partition Magic (of Power
> Quest).
Can you provide any more details about the partitions ?
a) Why doesn't the WinXP partition have a drive letter ? If they're all
FAT32 then Win98 should see them all.
b) Are the partitions FAT32 LBA (type 0x0C) or FAT32 CHS (type 0x0B) ?
c) Is the extended partition type 0x05 or 0x0F ?
I don't have any definite ideas about the problem but some more details
might help. Although the drive is 160GB you've only allocated about
73GB so it should all be accessible via 28-bit LBA.
Cheers,
--
Steven
Andrew
a. I run the WinXP Home edition.
If you assign the active partition, Partition Magic hides automatically the
other primary partitions, as having 2 active would call for disaster.
Therefore lack of the letter. If I want to start WinXP, then I make its
partition active and Win98 is automatically starred. My both OSs use the
letter C:, as working partition must be on the primary disk (disk 0) on the
partition C:. On the hard disk my WinXP partition is located directly after
the Win98 one.
b&c. My MoBo and hard disk support LBA48. My partitions, according to
Partition info are:
Win98se 0C (Hex) FAT32X
WinXP 1C FAT32X
Extended 0F Extended X
D: 0C FAT32
E: 0B FAT32
Unallocated.
(The WinXP, D:, and E: partitions use also FAT extensions - VFAT LFNS)
I must add that after resizing the WinXP partition (from Win98) to 35GB, I
could make accesibility checks on D: without restarting computer to Win98.
Yet, the E: partition was accessible under these conditions.
Regards,
Andrew
"Steven Saunderson" wrote:
> .
>
Steven Saunderson
<And...@discussions.microsoft.com> wrote:
> More details!
> a. I run the WinXP Home edition.
> If you assign the active partition, Partition Magic hides automatically the
> other primary partitions, as having 2 active would call for disaster.
> Therefore lack of the letter. If I want to start WinXP, then I make its
> partition active and Win98 is automatically starred.
This makes sense but it isn't really necessary. I used to setup disks
with two primary partitions (and an extended one) and install a backup
version of the OS on the second primary one. If the user got into big
problems I would change the bootable flag from the first to the second
and start the PC using the backup OS. Then I could fix the real OS in
the first partition and then restore the bootable flags so the PC ran
normally. It sounds like Partition Magic changes the type of the
partition (e.g. 0C to FF) to make it inaccessible. This shouldn't cause
a problem unless you want to access the disabled partition (e.g. to back
it up).
> Partition info are:
> Win98se 0C (Hex) FAT32X
> WinXP 1C FAT32X
> Extended 0F Extended X
> D: 0C FAT32
> E: 0B FAT32
It looks like D: is FAT32X (type 0x0C) which is good. I don't like the
fact that E: is type 0x0B. Win98 IO.SYS has a problem when encountering
a mix of LBA and CHS volumes in the extended partition.
Can you change the type of D: from 0x0B to 0x0C ? I think this will fix
the problem. If you can't then please check
<http://home.exetel.com.au/~phelum/w98.htm> to read about my fix for
Win98 IO.SYS.
Cheers,
--
Steven
Steven Saunderson
wrote:
> Can you change the type of D: from 0x0B to 0x0C ?
Oops, that should be change the type of E: from 0x0B to 0x0C.
Cheers,
--
Steven
Andrew
I'm afraid that it's impossible to make such a conversion in Partition Magic.
I have to apologize for informing you incorrectly about the D: partition.
In fact, both the D: and E: partitions are 0B (Hex).
Regards,
Andrew
"Steven Saunderson" wrote:
> .
>
Steven Saunderson
<And...@discussions.microsoft.com> wrote:
> Thanks for your comments and hints.
> I'm afraid that it's impossible to make such a conversion in Partition Magic.
> I have to apologize for informing you incorrectly about the D: partition.
> In fact, both the D: and E: partitions are 0B (Hex).
This sounds like a manifestation of the IO.SYS bug I mentioned. You
have CHS partitions in an LBA type extended partition. This is not
necessarily invalid (although a bit silly) but in your case I'd say it
is actually wrong because they all exceed the 8.4GB barrier.
You could try either a modified IO.SYS or use a disk editor program to
change the partition types from 0x0B to 0x0C.
Cheers,
--
Steven
Andrew
utilities on it. One of them was the ptedit32.exe, i.e., Partition Table
Editor v1.1 of 2002. The nice thing about this editor is that it is still
downloadable from the Internet and its interface is in plain English.
I used it to change my 0Bs to 0Cs, but I failed. To be more precise, I was
able to make such changes with this utility and save them (they even were in
place after rebooting the computer), but everything returned to the previous
situation, as soon, as I opened Partition Magic.
Although your reasoning about my logical partitions seems to be OK, there is
probably another limitation or maybe a deficiency of Partition Magic, which
doesn't allow it. By the way, I found on the Internet an another example of
the similar situation with 2 logical 0B partitions within the ExtenedX
partition (cf. www.goodells.net.multiboot.ptedit.htm).
I'm sure that I didn't make any mistake, so simple this interface was.
Its starting screen displays the master boot sector and master partition
table with its 4 entries and their types (in my case: 1C, 0C, 0F and 00 for
the Win98, WinXP, Extended and Unallocated partitions, respectively).
Clicking on 'Boot Record', displays all the boot record details of the
particular partitions.
Consecutive use of the 'Goto EPBR' option moves to the Extended partition
table with my chained logical volumes as the first entries.
Finally, the 'Set Type' option allows to change the partition type.
I would be grateful for your comments, if the above description is useful
somehow.
Regards,
Andrew
"Steven Saunderson" wrote:
> .
>
Steven Saunderson
<And...@discussions.microsoft.com> wrote:
> While browsing the Partition Magic installation CD-ROM, I found extra
> utilities on it. One of them was the ptedit32.exe, i.e., Partition Table
> Editor v1.1 of 2002. The nice thing about this editor is that it is still
> downloadable from the Internet and its interface is in plain English.
>
> I used it to change my 0Bs to 0Cs, but I failed. To be more precise, I was
> able to make such changes with this utility and save them (they even were in
> place after rebooting the computer), but everything returned to the previous
> situation, as soon, as I opened Partition Magic.
A simple test here might show whether we're on the right track. Use
Partition Magic to make your Win98 system partition active and then use
ptedit.exe (I assume you boot using a DOS floppy to use ptedit) to
change the partition types from 0B to 0C. Then you could start Win98
and see if it can see the partitions properly and also that you have no
phantom drives in Explorer. Phantom drives have a drive letter but if
you try to view them in Explorer it will tell you the volume isn't
formatted. If the partitions don't appear then the problem is
elsewhere.
> Although your reasoning about my logical partitions seems to be OK, there is
> probably another limitation or maybe a deficiency of Partition Magic, which
> doesn't allow it. By the way, I found on the Internet an another example of
> the similar situation with 2 logical 0B partitions within the ExtenedX
> partition (cf. www.goodells.net.multiboot.ptedit.htm).
The partition type code issue is a bit muddled due to historical
factors. Type 0x0B is FAT32 with CHS access and type 0x0C is FAT32 with
LBA access. I believe that Win98 respects this. But all versions of
Win NT always use LBA access. So XP doesn't care whether your
partitions are 0x0B or 0x0C; it always uses LBA. If I create a FAT32
volume in XP it always gets the 0x0B code even when it's past the 1024
cylinder boundary. So if Partition Magic does the same I wouldn't call
it a bug or even a deficiency. But it can cause problems with Win98
IO.SYS so it seems a bit silly to me.
So please try the ptedit test above and tell me if it helps. I think a
better long-term solution would be to make your system multiboot with
the Win98 system partition as the active partition. Then you could
select which O/S you want at boot time and not have to play with
changing the partition table. I think this can be done without mucking
up the drive letters in either O/S. Does this approach appeal to you ?
Cheers,
--
Steven
Andrew
partition active. This version doesn't have all options of the Windows
version. In order to complete the changes made to my hard drive(s), I have to
reboot to Win98se.
2. No, I never used ptedit.exe, which is the DOS version of this editor, but
ptedit32.exe, running it either from Win98 or from WinXP. Under such
circumstances, I never had phantom drives in Explorer.
3. Is use of the ptedit.exe (from DOS) essential for the suggested by you
test?
4. MS approach to multibooting has documented disadvantages, especially in
case you decide to get rid of Win98 at a later time. A better solution would
be multibooting approach of Partition Magic. My approach separating
completely both OSs isn't perfect either, but fortunately, I'm not switching
too often to Win98 and believe to abandon it anyway within a year or so.
Regards,
Andrew
"Steven Saunderson" wrote:
> .
>
Steven Saunderson
<And...@discussions.microsoft.com> wrote:
> 3. Is use of the ptedit.exe (from DOS) essential for the suggested by you
> test?
No, you could use any suitable program. But it might be safer to do the
changes outside of Win98 (e.g. DOS) because you are seeing the problem
when running Win98. Also you mentioned the difference after a reboot
which suggests that some of the effects of the change are only detected
when Win98 is starting.
> 4. MS approach to multibooting has documented disadvantages, especially in
> case you decide to get rid of Win98 at a later time.
Yup, nothing's perfect. For instance NTLDR has a limitation of 10
entries in the BOOT.INI file. Of course, only silly people like me will
ever hit this limit so it's not really a problem.
Cheers,
--
Steven
Andrew
and save them (either in Win98 or WinXP). They were in place after rebooting
the computer. However, these changes disappeared, after opening of Partition
Magic (either in DOS or in Windows). It seems, Partition Magic didn't accept
the changes, for some reason.
2. Just to be on a safe side, I performed the suggested by you test. This
time, I restarted the computer from Win98 to DOS and then ran pedit.exe from
a floppy). The results were the same as before.
3. To check, if my E: partitions (of only 7.5GB) wasn't a culprit, I used
Partition Magic from DOS (rescue disks) to enlarge it by 1 GB and then
repeated the test, but the results were the same, as before.
4. Some data listed in the Boot Record Table for the partition E: in
ptedit.exe seem to me strange, namely
- Hidden Sectors: 117852903
- First Cluster of Root: 141346
These are rather big numbers, whereas for D: they are: 63 and 2, respectively.
5. Finally, in my Extended Partition Table, there are 2 non-zero entries in
the Type column: 0B describing my D: partition (I corrected it to 0C) and 05,
which describes an Extended Partition and not the ExtendedX one, which should
have 0F entry, as in the Partition Table at sector 0. I don't understand this
either and I didn't correct it.
Regards,
Andrew
"Steven Saunderson" wrote:
> .
>
Steven Saunderson
<And...@discussions.microsoft.com> wrote:
> 2. Just to be on a safe side, I performed the suggested by you test. This
> time, I restarted the computer from Win98 to DOS and then ran pedit.exe from
> a floppy). The results were the same as before.
Thanks for trying.
> 4. Some data listed in the Boot Record Table for the partition E: in
> ptedit.exe seem to me strange, namely
> - Hidden Sectors: 117852903
> - First Cluster of Root: 141346
> These are rather big numbers, whereas for D: they are: 63 and 2, respectively.
These are strange values. The hidden sectors value suggests that the
data is nowhere near the boot record. This could indicate how Partition
Magic moves data when you resize a partition.
> 5. Finally, in my Extended Partition Table, there are 2 non-zero entries in
> the Type column: 0B describing my D: partition (I corrected it to 0C) and 05,
> which describes an Extended Partition and not the ExtendedX one, which should
> have 0F entry, as in the Partition Table at sector 0. I don't understand this
> either and I didn't correct it.
The 0x05 is correct. The continuation entries are always 0x05 even when
the extended partition starts with a 0x0F code.
I'm rather lost here because I don't know anything about Partition
Magic. Assume that originally your disk had two primary partitions and
then your extended one with two volumes. When you increased the size of
the second primary partition perhaps PM made space by moving the D:
volume to after the E: volume and changing the links in the extended
partition to suit. It would be easier to move 11GB than 30GB. As far
as I know each partition has to be contiguous but the volumes in the
extended partition can have spare areas between them and don't have to
be in ascending order by disk address.
It's a double-edged sword. PM is very clever in that it can resize
partitions but it might be producing layouts that confuse things like
Win98. It should be possible to determine your disk layout by using
something like Ranish Partition Manager but changing things to help
Win98 might cause problems when you later use PM to resize a partition
or select the other O/S.
Hopefully someone with ideas or knowledge of PM will chip in here. I'm
hesitant to suggest further changes due to the risk of wrecking your
setup.
It is possible to have Win98 and XP on a disk and select the one you
want by changing the boot flag using something like FDISK. This used to
be common in the old days and I still do it on some PCs.
Cheers,
--
Steven
Andrew
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.
> 1. These are strange values. The hidden sector values suggest that the data is nowhere near the boot record. This could indicate how Partition Magic moves data when you resize a partition.
My logical partitions D: and E: are not system partitions. They are so to
say chained within my Extended partition. Can these strange values mean that
the boot record for E: is located just before the beginning of E: and that
these values reflect their relative distance from the beginning of the
Extended partition? Is such a description used for logical partitions?
> 2. As far as I know each partition has to be contiguous but the volumes in the extended partition can have spare areas between them and don't have to be in ascending order by disk address.
This is a very important info that I was unaware of. Let me return here to
the PM resizing procedure.
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
Are these details somehow useful for confirmation of your idea about these
strange values?
> 3. It is possible to have Win98 and XP on a disk and select the one you want by changing the boot flag using something like FDISK.
You're completely right. One can easily do it, e.g. in the ptedit32.exe, by
changing the flags. 'Boot flags' 00 and 80 stand for not bootable and
bootable, and 'type flags' 0C and 1C stand for FAT32X and Hidden Fat32X
partitions, respectively. PM has also 2 additional utilities (BootDisk) for
activation and/or deactivation of a primary partition. One can easily change
them.
Regards,
Andrew
"Steven Saunderson" wrote:
> .
>
Hot-text
"Andrew" <And...@discussions.microsoft.com> wrote in message
news:D1457CCB-8B52-4BB2...@microsoft.com...
Steven Saunderson
<And...@discussions.microsoft.com> 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
Steven Saunderson
wrote:
> All Windows system put boots on C
Well yes but the truth is slightly reversed. DOS and Windows search a
disk for a partition with the boot indicator set before anything else.
Such a partition will always be found first and allocated the drive
letter C. Andrew is talking about changing the bootable flag in the
partition table entries and this will change which partition Windows
regards as C. The other primary partitions (if formatted acceptably)
will appear after all the logical partitions in the volume list.
Setting the boot indicator on more than one primary partition entry
normally causes the MBR code to have a hernia. I suppose one could
change this code to find the first and not worry about the rest.
Cheers,
--
Steven
Hot-text
win98 can not see the old FAT its a 16
Xp read all!
"Steven Saunderson" <phe...@Syd.au> wrote in message
news:tea6069fq535kpg2j...@4ax.com...
Hot-text
Right and true Steven!
"Steven Saunderson" <phe...@Syd.au> wrote in message
news:vah6069tijquumo2k...@4ax.com...
Andrew
Hot-text, I'm sorry to say, but I'm really fed up with your contributions!
You just post this junk now and again without even reading previous comments.
All your suggestions and guesses are flat wrong. D: is FAT32 and this was
clearly stated before. I think, it's better if you switch to another
discussion group instead of interfering with Steven's efforts to help me.
"Hot-text" wrote:
> .
>
Hot-text
microsoft.public.win98.disks.general for effective June 1, 2010 this
newsgroup will be closed..
I reading all the previous comments.
If Windows 98 can not read a Format, then the format is flat wrong for 98
not me.
My suggestions was for and to Steven's efforts in helping you out, For he
99.98% right and that 2% need input and Info.
You Just need to work with Steven and he help you out.
For little contributions i just give right or wrong will help him Thank it
out and fine the right Info for you!
And my old post or not junk but will work.
Next time, but not now you need to start C: at 1 Gb. for a Boot Drive only!
"Andrew" <And...@discussions.microsoft.com> wrote in message
news:478AA961-F846-4D03...@microsoft.com...
Andrew
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:
> .
>
Andrew
It's really time for you to say goodbye.
Steven Saunderson
<And...@discussions.microsoft.com> wrote:
> 3. If I understand properly, Win98 doesn't tolerate another primary active
> partition on the system*.
I assume that by "active" you mean the bootable indicator is set (0x80).
You're right that multiple active partitions are a no-no (only primary
partitions can be active) but it is the code in the MBR that will catch
this. Anyway, it's a silly thing to do even if the O/S doesn't catch
it. However Win98 (and others) have no problems with multiple primary
partitions. In the volume list (e.g. in Explorer) the first primary
will appear, then all the logical volumes (in the extended partition),
and then all the other (max 2 I guess) primaries.
If you want to test this while the system is set to run XP, run ptedit
from a DOS floppy, change the first primary from 0x1C to 0x0C, then set
the boot flag in the first partition and reset the boot flag in the
second. When the PC boots it should start Win98 and the XP volume will
appear as drive F. If you later boot from the floppy again and flip the
boot flags the PC should start XP when booted. If this doesn't happen
then there is something strange with your setup and we'll have to check
further.
I'm in a hurry at the moment and haven't read all of your post. Also,
if the doomsayers are correct, this newsgroup might be dead and we'll
have to move to alt.windows98. I'll follow up later.
Cheers,
--
Steven
Steven Saunderson
<And...@discussions.microsoft.com> wrote:
> 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
Yes, the DOS version has PowerQuest in it's list heading. Does the W98
version produce a list (stdout) that you can redirect to a file ? The
list might contain the details needed to resolve your problem.
> - 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.
You're quite right here. Larger clusters might be beneficial for some
streaming applications but the slack space overhead will probably
increase. Smaller clusters than recommended work but file access is
slower and Win98 utilities that read the entire FAT don't work in my
experience.
> 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.
I don't think the cluster size can be the problem because I doubt that
Win98 will even look at the volume when the partition type is 0x1C. But
I can't see how PM can safely move the extended partition when you
resize the WinXP partition so I wonder if it is using methods that
aren't apparent. This could have side effects that cause problems with
Win98. Shifting a partition up by 1GB (or 7GB) sounds risky to me.
Shifting the partition back sounds even harder to do safely. Changing
the cluster size is also very difficult without making a temporary copy
of all the data. Partition Magic is a very apt name.
Cheers,
--
Steven
Andrew
Thanks for your answers and ideas
> Does the W98 version produce a list (stdout) that you can redirect to a file ?
partinfo.exe for Win98 displays a nice table on the screen, which can be
copied to any document. In addition, there are several options to choose
from, e.g. Save As, Copy to Clipboard and more. I saved the results, as the
.txt file. It's only 22K.
In case everything fails, wouldn't be reasonable to:
- copy all files from D: and E: to a USB stick
- delete the D: and E: partitions from my drive
- delete my Extended partition
- resize the WinXP partition, let's say to 45 GB
- create the Extended partition
- create the D: and E: partitions (this time a bit bigger)
- copy the files from the USB stick back to D: and E:
Regards,
Andrew
"Steven Saunderson" wrote:
> .
>
Steven Saunderson
<And...@discussions.microsoft.com> wrote:
> partinfo.exe for Win98 displays a nice table on the screen, which can be
> copied to any document. In addition, there are several options to choose
> from, e.g. Save As, Copy to Clipboard and more. I saved the results, as the
> .txt file. It's only 22K.
This sounds good. I'd save the list(s) so you can check that your
primary partitions are still contiguous at the start of the disk. I
doubt that many people are concerned with partitions and disk layouts
nowadays (except when something goes wrong) so the subject is a bit of a
black art. It's quite simple really but just a bit alien.
> In case everything fails, wouldn't be reasonable to:
> - copy all files from D: and E: to a USB stick
> - delete the D: and E: partitions from my drive
> - delete my Extended partition
> - resize the WinXP partition, let's say to 45 GB
> - create the Extended partition
> - create the D: and E: partitions (this time a bit bigger)
> - copy the files from the USB stick back to D: and E:
Yes, I'd copy everything. The good thing about this is that you will
have a backup in case your disk crashes.
If you play with ptedit I'll be interested to hear how it goes.
Cheers,
--
Steven
Andrew
1. My primary partitions are contiguous, which I checked, but I'm confused
about my logical partitions, esp. about the locations of EPBRs. I just don't
feel it. I display them below for your opinion
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
Disk Geometry Info: Cyl: 19457, Head: 255, Sect/Track: 63
> 2. Yes, I'd copy everything. The good thing about this is that you will have a backup in case your disk crashes
You're completely right about the backup, but I rather meant remaking of my
logical partitions from scratch (without necessity to resize anything, i.e.
by taking the necessary space directly from the Unallocated partition -
adjacent to them) and then copying back all files from the USB stick. I hope
that then I should be free of any artifacts of the previous moving and
resizing operations, if any. Am I right?
3. As far as I remember, PowerQuest developed own methods of performing
various operations on partitions, with intelligent double-checking, and they
never disclosed them to the public. Instead, they have just patented them.
You can see below some of the numbers of the patents involved that they refer
to in their manual.
"This product and/or its use may be covered by one or more of the following
patents: 5,675,769; 5,706,472; 5,930,831; 6,088,778; 6,108,697; 6,108,759;
6,173,291; 6,178,487; 6,178,503; 6,185,575; 6,185,666; 6,253,300; 6,330,653;
and 6,377,958. Additional patents may be pending."
Regards,
Andrew
"Steven Saunderson" wrote:
> .
>
Steven Saunderson
<And...@discussions.microsoft.com> 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