On Restore Partition Labels Out of Order. How to Stop This?

[Radish]

OS = Win 7 Pro. x64
IFW v3.06
IFL v3.06

I have a recurring problem when I restore the boot partition (C:) from an image file. When I create an image file of the boot partition the order of all the partitions are labelled (by me) as the order in which they physically exist on the HD. So the order is:

C:, D:, E:, F:, G: and H:

When I restore the boot partition from the image file and then boot into the system the order of the partition labels is like this:

C:, G:, H:, D:, E: and F:

See, they are all re-arranged and only C: is the same as it was relative to the system when it was imaged. What this means is that every time I do restore I have to manually re-label the partitions into the order I prefer i.e. into the order of the physical partitions on the HD.

So my question is: Is there some setting I can make to force the partition labels to be the same as they were when the image was created?

P.S. Though I am on a Windows system I use the IFL (GUI) boot disk to do restores as I prefer it over the IFD (GUI). I would suspect that doing so makes no difference to this partition labelling issue. I should add that I'm not suggesting this is an issue with v3.06 - the same sort of thing was happening when I was using IFW v2.x.

[Bob Coleman]

I really don't understand what's being said here. Are these labels or drive letters?

[Radish]

Bob Coleman wrote: Are these labels or drive letters?

Okay they are drive letters in your speak. (Though I think strictly speaking they shouldn't be called that because they are not single physical HDDs - they are partitions on a single HDD. On that basis might refer to them as partition letters.) So I have:

C: = Boot partition
D: = Documents partition
(and so on)

Hope that helps. Do you have a solution for the problem?

[Brian K]

Radish,

Are partitions D: E: and F: inside an Extended Partition?

[Radish]

Brian K wrote: Are partitions D: E: and F: inside an Extended Partition?

Not quite. Scheme is like this (when I setup the partitions and letters/labels by myself when I do a complete fresh install of the system):

C: Primary Partition (boot partition)
D: Primary Partition
E: Primary Partition
F: Logical "Drive" in extended partition
G: Logical "Drive" in extended partition
H: Logical "Drive" in extended partition

And all those partitions are in progressive order as they physically exist on the HDD. So C: partition first, D: partition second - and so on through to H: partition which is the last partition on the HDD.

[Brian K]

I expressed my question badly. I should have said are the last 3 partitions in an extended partition. They are. So your partitions are being assigned default drive letters after a restore.

http://www.terabyteunlimited.com/kb/article.php?id=180

But why?

[tas3086]

This restore option may help:

Move to Original MBR Entry – If you select this option, Image for DOS will move the partition table entry of the restored partition to the same location in the master partition table as it had on the source drive. Image for DOS will also move the existing partition table entry to another location rather than overwrite it. You may want to enable this option if you use an environment that tracks master partition table entries, such as Linux.

[Radish]

Brian K wrote: But why?

Thanks for the KB article. Read it and first thought was trust Microsoft to do it a dumb way. Would seem to me the best way to deal with this is to consecutively label the primary partitions first so C: to E: (which takes care of the maximum number of primary partitions (3) on Windows unless the user only wants four partitions, all primary, in total). As far as I am aware if the user wants more than four partitions then they have to start using "volumes/drives" inside an extended partition. (The extended partition being, by my understanding, just one primary partition (the last of the four possible maximum) sub-divided into Logical "Drives/volumes".) Really the scheme would be best as label the primary partitions consecutively first and then consecutively label the Logical "Drives/Volumes" second - with all of that done according to the physical order of partitions on the HDD.

Anyway, I was just wondering why IFW/IFL isn't collecting the information on partition labelling when the C: partition image is created and then labelling all the partitions as they were when the image of C: (the boot partition) was made - and then restore that situation when C: (the boot partition) is restored from the image. (Now that I've typed that I can see that doing so might cause some difficulty if the HDD partitioning scheme was altered after the image was made of C: partition.)

Mmm... Need to think about this a bit more. Maybe I'm asking a stupid question based on false expectations of IFW/IFL and ignorance of understanding HDDs, which are very complex and beyond the understanding of my medium tech abilities.

[Brian K]

Radish wrote:
>. Maybe I'm asking a stupid
> question based on false expectations of IFW/IFL and ignorance of
> understanding HDDs, which are very complex and beyond the understanding of
> my medium tech abilities.

No, not a stupid question. Your drive letters should not change after a restore.

[Radish]

tas3086 wrote: This restore option may help: Move to Original MBR Entry – If you select this option, Image for DOS will move the partition table entry of the restored partition to the same location in the master partition table as it had on the source drive.

I don't think that is a concern for me. I only ever use IFW/IFL to image my boot partition which, with a default install of Windows, is always C: partition. When I restore from the image that partition is unfailingly restored with the label C:. It's not C: that I'm querying here - it's all the other labels being knocked out of sync compared to how they were when the C: partition was imaged off. It's not a disaster, only takes a few minutes to re-label manually - but it is annoying.

Maybe I just need to wait till Monday when the tech folks at TeraByte are back in the office and can respond here.