What happens if you *clone* your entire source drive (mine consists of
partitions C:, D:, E;, and F, over to a backup drive (in my case, to
another SATA drive in a hard disk enclosure), and then accidentally reboot,
with both powered on and connected? (i.e., both the internal source SATA
drive and the external one, each having identical partitions)? Will there
be a big issue here due to the conflicts between the two bootable drives
each having their Active Partition bits set?

I'm just guessing it may boot up to the internal source drive, and that
you'll see a bunch of new added drive letters in Windows Explorer (G, H, I,
J), but since only one drive can supposedly have its Active Partition bit
set, what really would happen? Additionally, I expect the drive letters
will be all messed up from that point onward. Like the D: partition would
NOW refer to the primary partition on the backup drive, etc (egads), since
they are enumerated first as I recall.

And if one does this, perhaps the destination backup drive magically gets
its Active Bit cleared, in which case it will no longer be a bootable clone
(at least until that bit is somehow reset first IF you replace the drives)

The primary partitions on either drive will
grab the first drive letters (C, D, E, F, Etc)
followed by the logical drives but in what
order is hard to say.

As to the external may not be seen as bootable
if your BIOS doesn't support bootable external
drives.

If the bit is reset it can be made active again.

--
JS
http://www.pagestart.com


"Bill in Co." <(E-Mail Removed)> wrote in message
news:u1RpN%(E-Mail Removed)...
> What happens if you *clone* your entire source drive (mine consists of
> partitions C:, D:, E;, and F, over to a backup drive (in my case, to
> another SATA drive in a hard disk enclosure), and then accidentally
> reboot, with both powered on and connected? (i.e., both the internal
> source SATA drive and the external one, each having identical partitions)?
> Will there be a big issue here due to the conflicts between the two
> bootable drives each having their Active Partition bits set?
>
> I'm just guessing it may boot up to the internal source drive, and that
> you'll see a bunch of new added drive letters in Windows Explorer (G, H,
> I, J), but since only one drive can supposedly have its Active Partition
> bit set, what really would happen? Additionally, I expect the drive
> letters will be all messed up from that point onward. Like the D:
> partition would NOW refer to the primary partition on the backup drive,
> etc (egads), since they are enumerated first as I recall.
>
> And if one does this, perhaps the destination backup drive magically gets
> its Active Bit cleared, in which case it will no longer be a bootable
> clone (at least until that bit is somehow reset first IF you replace the
> drives)
>

"Bill in Co." wrote:
> What happens if you *clone* your entire source drive (mine consists of partitions C:, D:, E;, and F, over to a
> backup drive (in my case, to another SATA drive in a hard disk enclosure), and then accidentally reboot, with both
> powered on and connected? (i.e., both the internal source SATA drive and the external one, each having identical
> partitions)? Will there be a big issue here due to the conflicts between the two bootable drives each having their
> Active Partition bits set?
>
> I'm just guessing it may boot up to the internal source drive, and that you'll see a bunch of new added drive letters
> in Windows Explorer (G, H, I, J), but since only one drive can supposedly have its Active Partition bit set, what
> really would happen? Additionally, I expect the drive letters will be all messed up from that point onward. Like
> the D: partition would NOW refer to the primary partition on the backup drive, etc (egads), since they are enumerated
> first as I recall.
>
> And if one does this, perhaps the destination backup drive magically gets its Active Bit cleared, in which case it
> will no longer be a bootable clone (at least until that bit is somehow reset first IF you replace the drives)

As long as the BIOS's Hard Drive Boot Priority isn't reset and you
haven't inter-changed the positions of the 2 HDs, the original OS will
boot up. It will not be a problem for the "parent" OS to see its clone,
and it will merely assign partition letters within its own tables for the
partitions on the clone HD. It will know those partitions by the letters
it assigns them, but the partitions in the clone HD aren't actually affected.

Be careful, though, not to let the clone OS boot up for its 1st run with
the "parent" OS still in view. For the clone OS's 1st run, have the "parent"
HD disconnected. You don't have to play with the BIOS's Hard Drive
Boot Order, as the absence of the "parent" HD will merely cause the
BIOS to select the clone HD as the boot drive. The clone OS's "active"
flag will have been copied (for some utilities this is a user option) and
the same partition in the clone HD will act as the "System (i.e. boot)
Partition". The clone OS will act as if it were the "parent", and it will refer
to its own partitions by the same letters as did the "parent" OS. After the
1st run of the clone OS, you can reconnect the "parent" HD, and either
OS can be started with the other OS visible to it. When the clone OS
starts up with its "parent" HD visible to it, it will assign drive letters to the
"parent" HD's partitions, but those will be for its own reference and won't
affect the "parent" partitions themselves. If you'd rather not get into
adding an entry in the System Partition's boot.ini file for the dual-boot
option, you can control which HD gets boot control by setting the Hard
Drive Boot Priority in the BIOS.

*TimDaniels*

Bill,
No matter how many 'cloned' drives you have there can be only ONE
ACTIVE (bootable) partition on any physical hard-drive. Due to the way
Windows recognises physical drives makes it impossible to boot to anything
but the original physical disk and the original partition. Look in the
"boot.ini" file in the root of your system dive and you will see the drives
listed NOT by drive letter but like this:

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP
Professional"
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="Microsoft Windows XP
Professional (Backup)"

....so you can see for yourself - Windows is using absolutes to know which
physical drive is which. Also, JS is right when he says that the external
drive may well not be seen as bootable even if you did create an entry for
it (as above.).
The clone will just appear as a set of drives with subsequent letters
assigned i.e. G:, H:, I: and J: (assuming you have no other fixed disks
installed)

==


Cheers, Tim Meddick, Peckham, London. :-)


*NB I have my own reasons for listing MY cloned drive in the boot.ini file
but rest assured - it is NOT advisable to boot into it as it will be seen by
Windows as a different installation and assign the next logical drive letter
to it after C: that is D: !! Unless EVERY reference to C: drive on your
system (and therefore, the cloned active partition) is replaced with the
replaceable parameters %SystemRoot% or %HOMEDRIVE% the cloned OS will not
load properly.


"Bill in Co." <(E-Mail Removed)> wrote in message
news:u1RpN%(E-Mail Removed)...
> What happens if you *clone* your entire source drive (mine consists of
> partitions C:, D:, E;, and F, over to a backup drive (in my case, to
> another SATA drive in a hard disk enclosure), and then accidentally
> reboot, with both powered on and connected? (i.e., both the internal
> source SATA drive and the external one, each having identical partitions)?
> Will there be a big issue here due to the conflicts between the two
> bootable drives each having their Active Partition bits set?
>
> I'm just guessing it may boot up to the internal source drive, and that
> you'll see a bunch of new added drive letters in Windows Explorer (G, H,
> I, J), but since only one drive can supposedly have its Active Partition
> bit set, what really would happen? Additionally, I expect the drive
> letters will be all messed up from that point onward. Like the D:
> partition would NOW refer to the primary partition on the backup drive,
> etc (egads), since they are enumerated first as I recall.
>
> And if one does this, perhaps the destination backup drive magically gets
> its Active Bit cleared, in which case it will no longer be a bootable
> clone (at least until that bit is somehow reset first IF you replace the
> drives)
>

Timothy Daniels wrote:
> "Bill in Co." wrote:
>> What happens if you *clone* your entire source drive (mine consists of
>> partitions C:, D:, E;, and F, over to a backup drive (in my case, to
>> another SATA drive in a hard disk enclosure), and then accidentally
>> reboot,
>> with both powered on and connected? (i.e., both the internal source SATA
>> drive and the external one, each having identical partitions)? Will
>> there
>> be a big issue here due to the conflicts between the two bootable drives
>> each having their Active Partition bits set? I'm just guessing it may
>> boot up to the internal source drive, and that
>> you'll see a bunch of new added drive letters in Windows Explorer (G, H,
>> I,
>> J), but since only one drive can supposedly have its Active Partition bit
>> set, what really would happen? Additionally, I expect the drive letters
>> will be all messed up from that point onward. Like the D: partition
>> would
>> NOW refer to the primary partition on the backup drive, etc (egads),
>> since
>> they are enumerated first as I recall. And if one does this, perhaps the
>> destination backup drive magically gets
>> its Active Bit cleared, in which case it will no longer be a bootable
>> clone
>> (at least until that bit is somehow reset first IF you replace the
>> drives)
>
> As long as the BIOS's Hard Drive Boot Priority isn't reset and you
> haven't inter-changed the positions of the 2 HDs, the original OS will
> boot up. It will not be a problem for the "parent" OS to see its clone,
> and it will merely assign partition letters within its own tables for the
> partitions on the clone HD. It will know those partitions by the letters
> it assigns them, but the partitions in the clone HD aren't actually
> affected.

Meaning if you later disconnect the clone HD and reboot, everything will be
exactly as it used to be, I expect.

BUT if you leave it connected, what used to be my small D: partition on the
source drive will no longer be designated as D:,.since the clone drive has a
primary partition, and THAT will now be D:, etc, etc. (since primary
partitions are all assigned first priority in the drive letter assignments).
And that will stay that way as long as both drives are connected. BUT if
I disconnect the clone drive, everything returns to normal. I presume. ??

> Be careful, though, not to let the clone OS boot up for its 1st run
> with
> the "parent" OS still in view. For the clone OS's 1st run, have the
> "parent"
> HD disconnected.

OK, Tim, I'm trying to understand this. Like what happens if you don't?
Would it permanently change the parent drive's system partition designation
in windows to D:, which obviously would really screw things up if I wanted
to use that as the system drive again, or what would be the problem?

> You don't have to play with the BIOS's Hard Drive
> Boot Order, as the absence of the "parent" HD will merely cause the
> BIOS to select the clone HD as the boot drive. The clone OS's "active"
> flag will have been copied (for some utilities this is a user option) and
> the same partition in the clone HD will act as the "System (i.e. boot)
> Partition". The clone OS will act as if it were the "parent", and it will
> refer to its own partitions by the same letters as did the "parent" OS.
> After the 1st run of the clone OS, you can reconnect the "parent" HD, and
> either OS can be started with the other OS visible to it. When the clone
> OS
> starts up with its "parent" HD visible to it, it will assign drive letters
> to
> the "parent" HD's partitions, but those will be for its own reference and
> won't affect the "parent" partitions themselves. If you'd rather not get
> into
> adding an entry in the System Partition's boot.ini file for the dual-boot
> option, you can control which HD gets boot control by setting the Hard
> Drive Boot Priority in the BIOS.
>
> *TimDaniels*

Bill in Co. wrote:
> Timothy Daniels wrote:
>> "Bill in Co." wrote:
>>> What happens if you *clone* your entire source drive (mine consists of
>>> partitions C:, D:, E;, and F, over to a backup drive (in my case, to
>>> another SATA drive in a hard disk enclosure), and then accidentally
>>> reboot,
>>> with both powered on and connected? (i.e., both the internal source SATA
>>> drive and the external one, each having identical partitions)? Will
>>> there
>>> be a big issue here due to the conflicts between the two bootable drives
>>> each having their Active Partition bits set? I'm just guessing it may
>>> boot up to the internal source drive, and that
>>> you'll see a bunch of new added drive letters in Windows Explorer (G, H,
>>> I,
>>> J), but since only one drive can supposedly have its Active Partition bit
>>> set, what really would happen? Additionally, I expect the drive letters
>>> will be all messed up from that point onward. Like the D: partition
>>> would
>>> NOW refer to the primary partition on the backup drive, etc (egads),
>>> since
>>> they are enumerated first as I recall. And if one does this, perhaps the
>>> destination backup drive magically gets
>>> its Active Bit cleared, in which case it will no longer be a bootable
>>> clone
>>> (at least until that bit is somehow reset first IF you replace the
>>> drives)
>> As long as the BIOS's Hard Drive Boot Priority isn't reset and you
>> haven't inter-changed the positions of the 2 HDs, the original OS will
>> boot up. It will not be a problem for the "parent" OS to see its clone,
>> and it will merely assign partition letters within its own tables for the
>> partitions on the clone HD. It will know those partitions by the letters
>> it assigns them, but the partitions in the clone HD aren't actually
>> affected.
>
> Meaning if you later disconnect the clone HD and reboot, everything will be
> exactly as it used to be, I expect.
>
> BUT if you leave it connected, what used to be my small D: partition on the
> source drive will no longer be designated as D:,.since the clone drive has a
> primary partition, and THAT will now be D:, etc, etc. (since primary
> partitions are all assigned first priority in the drive letter assignments).
> And that will stay that way as long as both drives are connected. BUT if
> I disconnect the clone drive, everything returns to normal. I presume. ??

You are right in that active partitions are assigned drive letters
before the others but they will not be assigned already assigned drive
letters. The I/O Manager's IoAssignDriveLetters function will honour
previously assigned drive letter assignments, drive letter assignments
are persistent on Windows NT system so the newly discovered drive will
be assigned another (unused) drive letter, your existing D drive will
keep its drive letter and the new drive will be assigned the next
available drive letter. The Mount Manager will store this information
in its database at HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices and the
next time the computer is booted the same drive letters will be
reassigned to the drives.



>> Be careful, though, not to let the clone OS boot up for its 1st run
>> with
>> the "parent" OS still in view. For the clone OS's 1st run, have the
>> "parent"
>> HD disconnected.
>
> OK, Tim, I'm trying to understand this. Like what happens if you don't?
> Would it permanently change the parent drive's system partition designation
> in windows to D:, which obviously would really screw things up if I wanted
> to use that as the system drive again, or what would be the problem?

No, because of the persistent nature of drive letter assignments the C
letter will be assigned to the already existing 'parent' drive and the
clone will be assigned the next available drive letter, the clone could
very well end up on drive G, it all depends on which letter is the next
one available. This in turn (having the clone on G will cause havoc
with the Windows installation because when Windows is installed many
entries pointing to the installation drive letter are written in the
registry, everything will point to C: and now the clone will find itself
on G: and before long the whole installation will crumble. Remember
that the clone is an *exact* copy so the clone has the same Mount
Manager database as the original installation, so the
IoAssignDriveLetters function will honour previously assigned drive
letters. If the 'parent' drive is not connected when the clone is
booted for the fist time it will interpret the Mount Manager database as
being invalid and it will assign drive letters following a present set
of rules and the first active partition (that used to boot the clone)
will be assigned drive letter C. On subsequent reboots any other
attached drives will be given letters other than C.

John

"Bill in Co." <(E-Mail Removed)> wrote in message
news:u1RpN%(E-Mail Removed)...
> What happens if you *clone* your entire source drive (mine consists of
> partitions C:, D:, E;, and F, over to a backup drive (in my case, to
> another SATA drive in a hard disk enclosure), and then accidentally
> reboot, with both powered on and connected? (i.e., both the internal
> source SATA drive and the external one, each having identical partitions)?
> Will there be a big issue here due to the conflicts between the two
> bootable drives each having their Active Partition bits set?
>
> I'm just guessing it may boot up to the internal source drive, and that
> you'll see a bunch of new added drive letters in Windows Explorer (G, H,
> I, J), but since only one drive can supposedly have its Active Partition
> bit set, what really would happen? Additionally, I expect the drive
> letters will be all messed up from that point onward. Like the D:
> partition would NOW refer to the primary partition on the backup drive,
> etc (egads), since they are enumerated first as I recall.
>
> And if one does this, perhaps the destination backup drive magically gets
> its Active Bit cleared, in which case it will no longer be a bootable
> clone (at least until that bit is somehow reset first IF you replace the
> drives)


Bill:
As I recall you & I have discussed this issue at some length in the past but
obviously the issue hasn't been clarified to your satisfaction. So let me
add my comments to the ones you've already received.

As I'm sure you'll surmise from our previous exchange of posts on this
subject my comments will be in the context of the Casper 5 disk-cloning
program. While by & large my comments should apply to any disk-cloning
program, there is one particular area where the Casper program deviates from
other disk-cloning programs that I'm familiar with (in an advantageous way I
might add) and which I'll get to by & by.

Let's proceed on the following basis...

1. As you've indicated, your "source" HDD (your day-to-day working HDD) is
multi-partitioned with four partitions - C:, D:, E:, & F:. Presumably you're
working with an optical drive so let's assign that component with the G:
drive letter, OK?

2. You've indicated that your "destination" HDD, i.e., the recipient of the
cloned contents of your source HDD is a SATA HDD contained in an external
enclosure. However you have not indicated whether that external device is
connected as a USB device or has SATA-to-SATA connectivity. So we'll cover
both configurations, OK?

3. Obviously your BIOS boot priority order or boot precedence indicates a
first HDD boot to your C: partition.

4. When you clone the entire contents of your source HDD to your destination
HDD, the four partitions thus created on the destination drive will be H:,
I:, J:, & K:, (obviously coinciding with the C:, D:, E:, & F: partitions on
your source HDD. Thus the contents of your source drive's C: partition will
be contained in the destination drive's H: partition, the source D:
partition in the I: partition, etc., etc.

5. Following the disk-cloning operation, with both the source & destination
drives connected, (and regardless whether your destination HDD is
USB-connected or has SATA-to-SATA connectivity with your system), nothing
will change re the drive letter assignments. Your system will boot to your
source drive's C: partition and that will be that.

The fact that your externally-connected SATA HDD may have SATA-to-SATA
connectivity (thus being treated as an *internal* HDD by the system) is
irrelevant (using the Casper program) insofar as any later potential (boot)
problem with boot/drive letter assignments affecting the destination HDD as
may occur with other disk-cloning programs.

As you have heard from one or more responders, and as I believe you're
aware, it is generally recommended that immediately following the
disk-cloning operation where the destination HDD is *internally* connected
(thus potentially bootable), that drive be disconnected from the system and
the boot made only with the source HDD connected. Or, the source HDD be
disconnected from the system and the boot made to the destination HDD (if
for no other reason than to determine that the clone "took" and the user
obviously has a bootable, functional drive). The point here is that *both"
drives (the source & destination HDDs) should not be both connected on the
first boot following the disk-cloning operation.

But with the Casper program the preceding practice is unnecessary, another
significant advantage of Casper. We have undertaken or witnessed hundreds of
disk-cloning operations and have never run into a single instance of any
problem in this area when both internally-connected source & destination
HDDs are connected following a disk-cloning operation and the boot is made
to either the source or destination HDD. The destination HDD will later boot
without any problem, its H: partition (in this example) will receive the C:
drive letter assignment.

If the destination HDD is an externally-connected USB device there's really
no problem (re this particular issue) to begin with since the USBEHD is not
a bootable device.

6. So now we come into the situation where for one reason or another, e.g.,
the source HDD becomes defective or the system becomes so corrupt that it is
unbootable & dysfunctional, etc., etc., so that it becomes necessary for the
user to use his/her cloned external (destination) HDD to restore their
system.

7. Again, if the destination HDD has SATA-to-SATA connectivity the user
could then boot directly to that drive and the system would assign drive
letters C:, D:, E:, & F: to the four partitions, regardless of the drive
letter assignments on that drive prior to the boot. The same would be true
should the user be employing another *internal* HDD as the destination HDD,
i.e., the recipient of the cloned contents of the source HDD.

8. If, on the other hand, the destination HDD was a USB-connected device and
thus non-bootable, the user would clone the contents of that drive to an
internally-connected HDD and again, the drive letter assignments would be
C:, D:, E:, & F: on the newly-cloned internal boot drive.

So when all is said & done is it not clear that the drive letter assignments
affecting the destination drive are irrelevant (in the context of this
disk-cloning process)? So that in your example it's of no consequence what
drive letters are assigned to each of the four partitions on the destination
drive. This destination drive is simply serving as a repository of the
cloned contents of the source disk, right? All we're really concerned with
is that (notwithstanding drive letter assignments) the contents of the
destination HDD are a precise copy of the source drive's contents. Is that
not so?

If & when the time comes that we will be using the destination HDD to
restore the system either by cloning the contents of that drive back to
another HDD, or should the destination HDD had been another internal HDD (or
an external HDD having SATA-to-SATA connectivity) so that we would be able
(should we desire) to employ any of those drives as the boot drive, the
drive letter assignments on the multi-partitioned boot drive would reflect
the original source drive's letter assignments.
Anna

"Anna" <(E-Mail Removed)> wrote:

>
>"Bill in Co." <(E-Mail Removed)> wrote in message
>news:u1RpN%(E-Mail Removed)...
>> What happens if you *clone* your entire source drive (mine consists of
>> partitions C:, D:, E;, and F, over to a backup drive (in my case, to
>> another SATA drive in a hard disk enclosure), and then accidentally
>> reboot, with both powered on and connected? (i.e., both the internal
>> source SATA drive and the external one, each having identical partitions)?
>> Will there be a big issue here due to the conflicts between the two
>> bootable drives each having their Active Partition bits set?
>>
>> I'm just guessing it may boot up to the internal source drive, and that
>> you'll see a bunch of new added drive letters in Windows Explorer (G, H,
>> I, J), but since only one drive can supposedly have its Active Partition
>> bit set, what really would happen? Additionally, I expect the drive
>> letters will be all messed up from that point onward. Like the D:
>> partition would NOW refer to the primary partition on the backup drive,
>> etc (egads), since they are enumerated first as I recall.
>>
>> And if one does this, perhaps the destination backup drive magically gets
>> its Active Bit cleared, in which case it will no longer be a bootable
>> clone (at least until that bit is somehow reset first IF you replace the
>> drives)
>
>
>Bill:
>As I recall you & I have discussed this issue at some length in the past but
>obviously the issue hasn't been clarified to your satisfaction. So let me
>add my comments to the ones you've already received.

Bill's skull is thicker than a nuclear-hardened shelter's walls.

Mike Torello wrote:
> "Anna" <(E-Mail Removed)> wrote:
>
>>
>> "Bill in Co." <(E-Mail Removed)> wrote in message
>> news:u1RpN%(E-Mail Removed)...
>>> What happens if you *clone* your entire source drive (mine consists of
>>> partitions C:, D:, E;, and F, over to a backup drive (in my case, to
>>> another SATA drive in a hard disk enclosure), and then accidentally
>>> reboot, with both powered on and connected? (i.e., both the internal
>>> source SATA drive and the external one, each having identical
>>> partitions)?
>>> Will there be a big issue here due to the conflicts between the two
>>> bootable drives each having their Active Partition bits set?
>>>
>>> I'm just guessing it may boot up to the internal source drive, and that
>>> you'll see a bunch of new added drive letters in Windows Explorer (G, H,
>>> I, J), but since only one drive can supposedly have its Active Partition
>>> bit set, what really would happen? Additionally, I expect the drive
>>> letters will be all messed up from that point onward. Like the D:
>>> partition would NOW refer to the primary partition on the backup drive,
>>> etc (egads), since they are enumerated first as I recall.
>>>
>>> And if one does this, perhaps the destination backup drive magically
>>> gets
>>> its Active Bit cleared, in which case it will no longer be a bootable
>>> clone (at least until that bit is somehow reset first IF you replace the
>>> drives)
>>
>>
>> Bill:
>> As I recall you & I have discussed this issue at some length in the past
>> but
>> obviously the issue hasn't been clarified to your satisfaction. So let me
>> add my comments to the ones you've already received.
>
> Bill's skull is thicker than a nuclear-hardened shelter's walls.

School must be out early today. Did you clear this with the hall monitor?

Thanks, John.

So if I now understand this correctly, the BEST and safest thing to do is to
one time just boot up the clone w/o the other internal boot drive connected
(which will also verify it), and that one time action will permanently
rebuild and set its registry entries in the MountedDevices key correctly for
that drive. Then after doing that, I'm safe no matter what I do with my
normal internal system drive (meaning, having the other drive connected or
disconnected.

Interestingly enough, I find I have two registry keys in there:
"MountedDevices", and "MountedDevices1", which are somewhat different.

In addition to my main internal SATA system drive, I have another internal
SATA drive which is used for copies of image backups in a single partition.

I just recently made a clone of my entire source drive to an external SATA
HD enclosure drive using ATI. It uses an eSATA interface between the
computer and that external hard drive), and is normally disconnected.

So hopefully I have this part down. If I missed something, pse advise.
Thanks.

John John - MVP wrote:
> Bill in Co. wrote:
>> Timothy Daniels wrote:
>>> "Bill in Co." wrote:
>>>> What happens if you *clone* your entire source drive (mine consists of
>>>> partitions C:, D:, E;, and F, over to a backup drive (in my case, to
>>>> another SATA drive in a hard disk enclosure), and then accidentally
>>>> reboot,
>>>> with both powered on and connected? (i.e., both the internal source
>>>> SATA
>>>> drive and the external one, each having identical partitions)? Will
>>>> there
>>>> be a big issue here due to the conflicts between the two bootable
>>>> drives
>>>> each having their Active Partition bits set? I'm just guessing it may
>>>> boot up to the internal source drive, and that
>>>> you'll see a bunch of new added drive letters in Windows Explorer (G,
>>>> H,
>>>> I,
>>>> J), but since only one drive can supposedly have its Active Partition
>>>> bit
>>>> set, what really would happen? Additionally, I expect the drive
>>>> letters
>>>> will be all messed up from that point onward. Like the D: partition
>>>> would
>>>> NOW refer to the primary partition on the backup drive, etc (egads),
>>>> since
>>>> they are enumerated first as I recall. And if one does this, perhaps
>>>> the
>>>> destination backup drive magically gets
>>>> its Active Bit cleared, in which case it will no longer be a bootable
>>>> clone
>>>> (at least until that bit is somehow reset first IF you replace the
>>>> drives)
>>> As long as the BIOS's Hard Drive Boot Priority isn't reset and you
>>> haven't inter-changed the positions of the 2 HDs, the original OS will
>>> boot up. It will not be a problem for the "parent" OS to see its clone,
>>> and it will merely assign partition letters within its own tables for
>>> the
>>> partitions on the clone HD. It will know those partitions by the
>>> letters
>>> it assigns them, but the partitions in the clone HD aren't actually
>>> affected.
>>
>> Meaning if you later disconnect the clone HD and reboot, everything will
>> be
>> exactly as it used to be, I expect.
>>
>> BUT if you leave it connected, what used to be my small D: partition on
>> the
>> source drive will no longer be designated as D:,.since the clone drive
>> has a
>> primary partition, and THAT will now be D:, etc, etc. (since primary
>> partitions are all assigned first priority in the drive letter
>> assignments).
>> And that will stay that way as long as both drives are connected. BUT
>> if
>> I disconnect the clone drive, everything returns to normal. I presume.
>> ??
>
> You are right in that active partitions are assigned drive letters
> before the others but they will not be assigned already assigned drive
> letters. The I/O Manager's IoAssignDriveLetters function will honour
> previously assigned drive letter assignments, drive letter assignments
> are persistent on Windows NT system so the newly discovered drive will
> be assigned another (unused) drive letter, your existing D drive will
> keep its drive letter and the new drive will be assigned the next
> available drive letter. The Mount Manager will store this information
> in its database at HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices and the
> next time the computer is booted the same drive letters will be
> reassigned to the drives.
>
>
>
>>> Be careful, though, not to let the clone OS boot up for its 1st run
>>> with
>>> the "parent" OS still in view. For the clone OS's 1st run, have the
>>> "parent"
>>> HD disconnected.
>>
>> OK, Tim, I'm trying to understand this. Like what happens if you don't?
>> Would it permanently change the parent drive's system partition
>> designation
>> in windows to D:, which obviously would really screw things up if I
>> wanted
>> to use that as the system drive again, or what would be the problem?
>
> No, because of the persistent nature of drive letter assignments the C
> letter will be assigned to the already existing 'parent' drive and the
> clone will be assigned the next available drive letter, the clone could
> very well end up on drive G, it all depends on which letter is the next
> one available. This in turn (having the clone on G will cause havoc
> with the Windows installation because when Windows is installed many
> entries pointing to the installation drive letter are written in the
> registry, everything will point to C: and now the clone will find itself
> on G: and before long the whole installation will crumble. Remember
> that the clone is an *exact* copy so the clone has the same Mount
> Manager database as the original installation, so the
> IoAssignDriveLetters function will honour previously assigned drive
> letters. If the 'parent' drive is not connected when the clone is
> booted for the fist time it will interpret the Mount Manager database as
> being invalid and it will assign drive letters following a present set
> of rules and the first active partition (that used to boot the clone)
> will be assigned drive letter C. On subsequent reboots any other
> attached drives will be given letters other than C.
>
> John