You prove my case - that the letter name by which the "parent"
Windows OS knows its own partition (assigned to it by the
installer) will be the name that the clone will always call its own
partition (when it is running, naturally). Because a clone contains
exactly the same information, it too will call its own partition by
the same name (when it - the clone - is running). So the two OSes
(the "parent" and its clone) will refer to their own partitions by the
same name, which is no problem because they won't be running
at the time, and who but the running OS cares what each partition
is called, anyway? Of course, this implies that some or all partitions
will be renamed according to which OS is running, but as long as
there are no shortcuts that include the name of another partition,
there will be no problem.
You mention a case in which a clone would assign itself a name
other than that of its "parent" OS. How could that happen? If
that happened, it would immediately no longer be a clone. What
would change it from a copy of its "parent" to some errant child
that decided to rename itself? And since it really doesn't know
that it's a clone, what would cause an OS to spontaneously rename
its partition?
*TimDaniels*
"John John (MVP)" wrote:
> If he cloned an installation residing on drive "C" to another partition on the
> disk and if the clone adopts another drive letter when it boots, lets say
> drive "D" for example, then there will be serious problems! The Windows
> installation must *always* retain the drive letter onto which it was
> installed, if your Windows installation is installed on "C:" do a search in
> your registry for C: and the importance of maintaining the installation drive
> letter will become clearly apparent, shortcuts will be the least of your
> problems if the Windows volume is assigned a different drive letter!
>
> John
>
>
> Timothy Daniels wrote:
>
>> Of what importance is the drive letter that a Windows OS uses
>> while it is running? As long as there are no shorcuts which include
>> the name of a partition, there will be no problem. Are you
>> assuming that there are such shortcuts?
>>
>> *TimDaniels*
>>
>> "John John (MVP)" wrote:
>>
>>>Has the cloned installation retained the same drive letter as the parent? I
>>>suspect that it hasn't and that this is the cause of your problems. Boot to
>>>the parent installation and at the Command
>>>Prompt issue:
>>>
>>>set systemroot
>>>
>>>Then boot to the clone and issue the same command, both should
>>>return the same drive letter, if not that is the cause of your problems.
>>>
>>>John
>>>
>>>Dennis Wilson wrote:
>>>
>>>
>>>>I used Partition Magic to clone the partition containing my new Windows
>>>>XP installation. Both are on the same hard drive, and they're the only
>>>>two partitions on it. Basically, this just gives me a backup of my
>>>>system which I can use to copy back over the original if the original
>>>>(the one on Partion 1) gets corrupted. I keep Partition 2 marked
>>>>"hidden" and therefore inacessible most of the time, though I will
>>>>occasionally use BootMagic to boot into Partition 2 to copy a deleted
>>>>file or something. This backup method worked perfectly for me for all the
>>>>years I've used
>>>>it. Until now. I recently built a new computer, and as usual I
>>>>installed Windows and then all my apps and then cloned the entire
>>>>"install" onto a new partition. But after the cloning, many of my apps
>>>>needed to have their
>>>>configurations redone, and those that require "activation" need to
>>>>be RE-activated. It's as if my apps can't find the registry. Yet the
>>>>drive letter assignments all seem right, and I believe the boot.ini
>>>>files are written correctly as well. The one on partition 1 reads: [boot
>>>>loader]
>>>> timeout=0
>>>> default=multi(0)disk(0)rdisk(0)partition(1)\WINDOW S
>>>> [operating systems]
>>>> multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windo ws XP 1"
>>>> multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windo ws XP 2"
>>>>
>>>>The one on Partition 2 is the same, except the [boot loader] line reads:
>>>>
>>>> default=multi(0)disk(0)rdisk(0)partition(2)\WINDOW S
>>>>
>>>>The problem was the same on both partitions, and the result was the same
>>>>when I wiped the drive and reinstalled everything from scratch. Needless to
>>>>say, I can't figure out the reason for this behavior. The
>>>>only difference between this machine and all the other PCs I've built is
>>>>that this is the first one that has SATA hard drives instead of IDE; the
>>>>only IDE device on this system is an HP DVD+/-R recorder. Can anyone
>>>>suggest what I might have overlooked, or what I can do to get my apps able
>>>>to read their config info again?
>>>>
>>>>Thanks.
>>>>** Posted from http://www.teranews.com **
>>
>>
The problem is that the drive letters are assigned based on disk and
partition signatures and that the signatures and letter assignments are
recorded in the registry. When the clone is booted it will respect the
letter assignments in the registry and the new (cloned) Windows
installation will not keep its originally assigned drive letter, the C
drive letter will be assigned to the parent drive so it won't be
available for the clone.
John
Timothy Daniels wrote:
> You prove my case - that the letter name by which the "parent"
> Windows OS knows its own partition (assigned to it by the
> installer) will be the name that the clone will always call its own
> partition (when it is running, naturally). Because a clone contains
> exactly the same information, it too will call its own partition by
> the same name (when it - the clone - is running). So the two OSes
> (the "parent" and its clone) will refer to their own partitions by the
> same name, which is no problem because they won't be running
> at the time, and who but the running OS cares what each partition
> is called, anyway? Of course, this implies that some or all partitions
> will be renamed according to which OS is running, but as long as
> there are no shortcuts that include the name of another partition,
> there will be no problem.
>
> You mention a case in which a clone would assign itself a name
> other than that of its "parent" OS. How could that happen? If
> that happened, it would immediately no longer be a clone. What
> would change it from a copy of its "parent" to some errant child
> that decided to rename itself? And since it really doesn't know
> that it's a clone, what would cause an OS to spontaneously rename
> its partition?
>
> *TimDaniels*
>
> "John John (MVP)" wrote:
>
>>If he cloned an installation residing on drive "C" to another partition on the
>>disk and if the clone adopts another drive letter when it boots, lets say
>>drive "D" for example, then there will be serious problems! The Windows
>>installation must *always* retain the drive letter onto which it was
>>installed, if your Windows installation is installed on "C:" do a search in
>>your registry for C: and the importance of maintaining the installation drive
>>letter will become clearly apparent, shortcuts will be the least of your
>>problems if the Windows volume is assigned a different drive letter!
>>
>>John
>>
>>
>>Timothy Daniels wrote:
>>
>>
>>>Of what importance is the drive letter that a Windows OS uses
>>>while it is running? As long as there are no shorcuts which include
>>>the name of a partition, there will be no problem. Are you
>>>assuming that there are such shortcuts?
>>>
>>>*TimDaniels*
>>>
>>>"John John (MVP)" wrote:
>>>
>>>
>>>>Has the cloned installation retained the same drive letter as the parent? I
>>>>suspect that it hasn't and that this is the cause of your problems. Boot to
>>>>the parent installation and at the Command
>>>>Prompt issue:
>>>>
>>>>set systemroot
>>>>
>>>>Then boot to the clone and issue the same command, both should
>>>>return the same drive letter, if not that is the cause of your problems.
>>>>
>>>>John
>>>>
>>>>Dennis Wilson wrote:
>>>>
>>>>
>>>>
>>>>>I used Partition Magic to clone the partition containing my new Windows
>>>>>XP installation. Both are on the same hard drive, and they're the only
>>>>>two partitions on it. Basically, this just gives me a backup of my
>>>>>system which I can use to copy back over the original if the original
>>>>>(the one on Partion 1) gets corrupted. I keep Partition 2 marked
>>>>>"hidden" and therefore inacessible most of the time, though I will
>>>>>occasionally use BootMagic to boot into Partition 2 to copy a deleted
>>>>>file or something. This backup method worked perfectly for me for all the
>>>>>years I've used
>>>>>it. Until now. I recently built a new computer, and as usual I
>>>>>installed Windows and then all my apps and then cloned the entire
>>>>>"install" onto a new partition. But after the cloning, many of my apps
>>>>>needed to have their
>>>>>configurations redone, and those that require "activation" need to
>>>>>be RE-activated. It's as if my apps can't find the registry. Yet the
>>>>>drive letter assignments all seem right, and I believe the boot.ini
>>>>>files are written correctly as well. The one on partition 1 reads: [boot
>>>>>loader]
>>>>> timeout=0
>>>>> default=multi(0)disk(0)rdisk(0)partition(1)\WINDOW S
>>>>> [operating systems]
>>>>> multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windo ws XP 1"
>>>>> multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windo ws XP 2"
>>>>>
>>>>>The one on Partition 2 is the same, except the [boot loader] line reads:
>>>>>
>>>>> default=multi(0)disk(0)rdisk(0)partition(2)\WINDOW S
>>>>>
>>>>>The problem was the same on both partitions, and the result was the same
>>>>>when I wiped the drive and reinstalled everything from scratch. Needless to
>>>>>say, I can't figure out the reason for this behavior. The
>>>>>only difference between this machine and all the other PCs I've built is
>>>>>that this is the first one that has SATA hard drives instead of IDE; the
>>>>>only IDE device on this system is an HP DVD+/-R recorder. Can anyone
>>>>>suggest what I might have overlooked, or what I can do to get my apps able
>>>>>to read their config info again?
>>>>>
>>>>>Thanks.
>>>>>** Posted from http://www.teranews.com **
>>>
>>>
>
Have you ever seen this to occur? In about 4 years of making clones
on hard drives, I have never seen a clone rename its partition - it always
uses the same name that its "parent" OS used to refer to its own partition.
If drive letters were assigned based on disk and partition signatures, why
does the installer always choose "C:" if that is available? When you say
"When the clone is booted it will respect the letter assignments in the
registry...", I assume that you mean its own (the clone's) registry, as it
is unlikely to be reading any other registry. So why would the clone not
keep and "respect" what it finds in its own registry? After all, it doesn't
know that it is a clone. And if it were to rename its own partition, how
would it know what to name the partition that contains its "parent"?
Wouldn't it have to first do a search for any other Windows OSes in the
system and then to read the registries of each one to learn what those
OSes call their own partitions so as not to have a conflict? The problems
involved with having 6 clones on one hard drive (as I have had) boggle
the mind. I suspect that the re-naming problem, if it has occurred for you,
involves some other mechanism. Have you always removed the "parent"
OS from view before starting up the clone for its first run? Only in such
a case have I ever seen anomalies of any form whatsoever.
*TimDaniels*
"John John (MVP)" wrote:
> The problem is that the drive letters are assigned based on disk and partition
> signatures and that the signatures and letter assignments are recorded in the
> registry. When the clone is booted it will respect the letter assignments in
> the registry and the new (cloned) Windows installation will not keep its
> originally assigned drive letter, the C drive letter will be assigned to the
> parent drive so it won't be available for the clone.
>
> John
>
>
> Timothy Daniels wrote:
>
>> You prove my case - that the letter name by which the "parent"
>> Windows OS knows its own partition (assigned to it by the
>> installer) will be the name that the clone will always call its own
>> partition (when it is running, naturally). Because a clone contains
>> exactly the same information, it too will call its own partition by
>> the same name (when it - the clone - is running). So the two OSes
>> (the "parent" and its clone) will refer to their own partitions by the
>> same name, which is no problem because they won't be running
>> at the time, and who but the running OS cares what each partition
>> is called, anyway? Of course, this implies that some or all partitions
>> will be renamed according to which OS is running, but as long as
>> there are no shortcuts that include the name of another partition,
>> there will be no problem.
>>
>> You mention a case in which a clone would assign itself a name
>> other than that of its "parent" OS. How could that happen? If
>> that happened, it would immediately no longer be a clone. What
>> would change it from a copy of its "parent" to some errant child
>> that decided to rename itself? And since it really doesn't know
>> that it's a clone, what would cause an OS to spontaneously rename
>> its partition?
>>
>> *TimDaniels*
>>
>> "John John (MVP)" wrote:
>>
>>>If he cloned an installation residing on drive "C" to another partition on
>>>the disk and if the clone adopts another drive letter when it boots, lets say
>>>drive "D" for example, then there will be serious problems! The Windows
>>>installation must *always* retain the drive letter onto which it was
>>>installed, if your Windows installation is installed on "C:" do a search in
>>>your registry for C: and the importance of maintaining the installation drive
>>>letter will become clearly apparent, shortcuts will be the least of your
>>>problems if the Windows volume is assigned a different drive letter!
>>>
>>>John
>>>
>>>
>>>Timothy Daniels wrote:
>>>
>>>
>>>>Of what importance is the drive letter that a Windows OS uses
>>>>while it is running? As long as there are no shorcuts which include
>>>>the name of a partition, there will be no problem. Are you
>>>>assuming that there are such shortcuts?
>>>>
>>>>*TimDaniels*
>>>>
>>>>"John John (MVP)" wrote:
>>>>
>>>>
>>>>>Has the cloned installation retained the same drive letter as the parent?
>>>>>I suspect that it hasn't and that this is the cause of your problems. Boot
>>>>>to the parent installation and at the Command
>>>>>Prompt issue:
>>>>>
>>>>>set systemroot
>>>>>
>>>>>Then boot to the clone and issue the same command, both should
>>>>>return the same drive letter, if not that is the cause of your problems.
>>>>>
>>>>>John
>>>>>
>>>>>Dennis Wilson wrote:
>>>>>
>>>>>
>>>>>
>>>>>>I used Partition Magic to clone the partition containing my new Windows
>>>>>>XP installation. Both are on the same hard drive, and they're the only
>>>>>>two partitions on it. Basically, this just gives me a backup of my
>>>>>>system which I can use to copy back over the original if the original
>>>>>>(the one on Partion 1) gets corrupted. I keep Partition 2 marked
>>>>>>"hidden" and therefore inacessible most of the time, though I will
>>>>>>occasionally use BootMagic to boot into Partition 2 to copy a deleted
>>>>>>file or something. This backup method worked perfectly for me for all the
>>>>>>years I've used
>>>>>>it. Until now. I recently built a new computer, and as usual I
>>>>>>installed Windows and then all my apps and then cloned the entire
>>>>>>"install" onto a new partition. But after the cloning, many of my apps
>>>>>>needed to have their
>>>>>>configurations redone, and those that require "activation" need to
>>>>>>be RE-activated. It's as if my apps can't find the registry. Yet the
>>>>>>drive letter assignments all seem right, and I believe the boot.ini
>>>>>>files are written correctly as well. The one on partition 1 reads: [boot
>>>>>>loader]
>>>>>> timeout=0
>>>>>> default=multi(0)disk(0)rdisk(0)partition(1)\WINDOW S
>>>>>> [operating systems]
>>>>>> multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windo ws XP 1"
>>>>>> multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windo ws XP 2"
>>>>>>
>>>>>>The one on Partition 2 is the same, except the [boot loader] line reads:
>>>>>>
>>>>>> default=multi(0)disk(0)rdisk(0)partition(2)\WINDOW S
>>>>>>
>>>>>>The problem was the same on both partitions, and the result was the same
>>>>>>when I wiped the drive and reinstalled everything from scratch. Needless
>>>>>>to say, I can't figure out the reason for this behavior. The
>>>>>>only difference between this machine and all the other PCs I've built is
>>>>>>that this is the first one that has SATA hard drives instead of IDE; the
>>>>>>only IDE device on this system is an HP DVD+/-R recorder. Can anyone
>>>>>>suggest what I might have overlooked, or what I can do to get my apps able
>>>>>>to read their config info again?
>>>>>>
>>>>>>Thanks.
>>>>>>** Posted from http://www.teranews.com **
>>>>
>>>>
>>
Yes! Many times! The clone has the same MountedDevices key and
information and when the Windows installation is booted the information
in the key is *always* respected and the drive letters will be assigned
accordinly. It's nothing new, we have had lengthy discussions about
this in the past.
John
Timothy Daniels wrote:
> Have you ever seen this to occur? In about 4 years of making clones
> on hard drives, I have never seen a clone rename its partition - it always
> uses the same name that its "parent" OS used to refer to its own partition.
> If drive letters were assigned based on disk and partition signatures, why
> does the installer always choose "C:" if that is available? When you say
> "When the clone is booted it will respect the letter assignments in the
> registry...", I assume that you mean its own (the clone's) registry, as it
> is unlikely to be reading any other registry. So why would the clone not
> keep and "respect" what it finds in its own registry? After all, it doesn't
> know that it is a clone. And if it were to rename its own partition, how
> would it know what to name the partition that contains its "parent"?
> Wouldn't it have to first do a search for any other Windows OSes in the
> system and then to read the registries of each one to learn what those
> OSes call their own partitions so as not to have a conflict? The problems
> involved with having 6 clones on one hard drive (as I have had) boggle
> the mind. I suspect that the re-naming problem, if it has occurred for you,
> involves some other mechanism. Have you always removed the "parent"
> OS from view before starting up the clone for its first run? Only in such
> a case have I ever seen anomalies of any form whatsoever.
>
> *TimDaniels*
>
>
> "John John (MVP)" wrote:
>
>>The problem is that the drive letters are assigned based on disk and partition
>>signatures and that the signatures and letter assignments are recorded in the
>>registry. When the clone is booted it will respect the letter assignments in
>>the registry and the new (cloned) Windows installation will not keep its
>>originally assigned drive letter, the C drive letter will be assigned to the
>>parent drive so it won't be available for the clone.
>>
>>John
>>
>>
>>Timothy Daniels wrote:
>>
>>
>>>You prove my case - that the letter name by which the "parent"
>>>Windows OS knows its own partition (assigned to it by the
>>>installer) will be the name that the clone will always call its own
>>>partition (when it is running, naturally). Because a clone contains
>>>exactly the same information, it too will call its own partition by
>>>the same name (when it - the clone - is running). So the two OSes
>>>(the "parent" and its clone) will refer to their own partitions by the
>>>same name, which is no problem because they won't be running
>>>at the time, and who but the running OS cares what each partition
>>>is called, anyway? Of course, this implies that some or all partitions
>>>will be renamed according to which OS is running, but as long as
>>>there are no shortcuts that include the name of another partition,
>>>there will be no problem.
>>>
>>>You mention a case in which a clone would assign itself a name
>>>other than that of its "parent" OS. How could that happen? If
>>>that happened, it would immediately no longer be a clone. What
>>>would change it from a copy of its "parent" to some errant child
>>>that decided to rename itself? And since it really doesn't know
>>>that it's a clone, what would cause an OS to spontaneously rename
>>>its partition?
>>>
>>>*TimDaniels*
>>>
>>>"John John (MVP)" wrote:
>>>
>>>
>>>>If he cloned an installation residing on drive "C" to another partition on
>>>>the disk and if the clone adopts another drive letter when it boots, lets say
>>>>drive "D" for example, then there will be serious problems! The Windows
>>>>installation must *always* retain the drive letter onto which it was
>>>>installed, if your Windows installation is installed on "C:" do a search in
>>>>your registry for C: and the importance of maintaining the installation drive
>>>>letter will become clearly apparent, shortcuts will be the least of your
>>>>problems if the Windows volume is assigned a different drive letter!
>>>>
>>>>John
>>>>
>>>>
>>>>Timothy Daniels wrote:
>>>>
>>>>
>>>>
>>>>>Of what importance is the drive letter that a Windows OS uses
>>>>>while it is running? As long as there are no shorcuts which include
>>>>>the name of a partition, there will be no problem. Are you
>>>>>assuming that there are such shortcuts?
>>>>>
>>>>>*TimDaniels*
>>>>>
>>>>>"John John (MVP)" wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Has the cloned installation retained the same drive letter as the parent?
>>>>>>I suspect that it hasn't and that this is the cause of your problems. Boot
>>>>>>to the parent installation and at the Command
>>>>>>Prompt issue:
>>>>>>
>>>>>>set systemroot
>>>>>>
>>>>>>Then boot to the clone and issue the same command, both should
>>>>>>return the same drive letter, if not that is the cause of your problems.
>>>>>>
>>>>>>John
>>>>>>
>>>>>>Dennis Wilson wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>I used Partition Magic to clone the partition containing my new Windows
>>>>>>>XP installation. Both are on the same hard drive, and they're the only
>>>>>>>two partitions on it. Basically, this just gives me a backup of my
>>>>>>>system which I can use to copy back over the original if the original
>>>>>>>(the one on Partion 1) gets corrupted. I keep Partition 2 marked
>>>>>>>"hidden" and therefore inacessible most of the time, though I will
>>>>>>>occasionally use BootMagic to boot into Partition 2 to copy a deleted
>>>>>>>file or something. This backup method worked perfectly for me for all the
>>>>>>>years I've used
>>>>>>>it. Until now. I recently built a new computer, and as usual I
>>>>>>>installed Windows and then all my apps and then cloned the entire
>>>>>>>"install" onto a new partition. But after the cloning, many of my apps
>>>>>>>needed to have their
>>>>>>>configurations redone, and those that require "activation" need to
>>>>>>>be RE-activated. It's as if my apps can't find the registry. Yet the
>>>>>>>drive letter assignments all seem right, and I believe the boot.ini
>>>>>>>files are written correctly as well. The one on partition 1 reads: [boot
>>>>>>>loader]
>>>>>>> timeout=0
>>>>>>> default=multi(0)disk(0)rdisk(0)partition(1)\WINDOW S
>>>>>>> [operating systems]
>>>>>>> multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windo ws XP 1"
>>>>>>> multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windo ws XP 2"
>>>>>>>
>>>>>>>The one on Partition 2 is the same, except the [boot loader] line reads:
>>>>>>>
>>>>>>> default=multi(0)disk(0)rdisk(0)partition(2)\WINDOW S
>>>>>>>
>>>>>>>The problem was the same on both partitions, and the result was the same
>>>>>>>when I wiped the drive and reinstalled everything from scratch. Needless
>>>>>>>to say, I can't figure out the reason for this behavior. The
>>>>>>>only difference between this machine and all the other PCs I've built is
>>>>>>>that this is the first one that has SATA hard drives instead of IDE; the
>>>>>>>only IDE device on this system is an HP DVD+/-R recorder. Can anyone
>>>>>>>suggest what I might have overlooked, or what I can do to get my apps able
>>>>>>>to read their config info again?
>>>>>>>
>>>>>>>Thanks.
>>>>>>>** Posted from http://www.teranews.com **
>>>>>
>>>>>
>
>
Is this consistent behavior? It's strange that your procedure leads to
this, and my procedure has not in 4 years of cloning. In that period
of time, I have *never* seen this to occur. In my experience, the
clone has *always* referred to its own partition by the same letter
name as its "parent" did, and my experience has been with Drive
Image, Ghost, and most recently with Casper. In the past, we may
have had discussions about *why* you observe what you do, but
not about why our observations differ so consistently. I think that
it may be due to the procedures or the utilities that we use to do the
cloning. Do you clone entire hard drives, or do you clone single
partitions? (I only clone single partitions that contain the OS.)
What cloning utility did you use when this re-naming occurred?
*TimDaniels*
"John John (MVP)" wrote:
> Yes! Many times! The clone has the same MountedDevices key and information
> and when the Windows installation is booted the information in the key is
> *always* respected and the drive letters will be assigned accordinly. It's
> nothing new, we have had lengthy discussions about this in the past.
>
> John
>
> Timothy Daniels wrote:
>
>> Have you ever seen this to occur? In about 4 years of making clones
>> on hard drives, I have never seen a clone rename its partition - it always
>> uses the same name that its "parent" OS used to refer to its own partition.
>> If drive letters were assigned based on disk and partition signatures, why
>> does the installer always choose "C:" if that is available? When you say
>> "When the clone is booted it will respect the letter assignments in the
>> registry...", I assume that you mean its own (the clone's) registry, as it
>> is unlikely to be reading any other registry. So why would the clone not
>> keep and "respect" what it finds in its own registry? After all, it doesn't
>> know that it is a clone. And if it were to rename its own partition, how
>> would it know what to name the partition that contains its "parent"?
>> Wouldn't it have to first do a search for any other Windows OSes in the
>> system and then to read the registries of each one to learn what those
>> OSes call their own partitions so as not to have a conflict? The problems
>> involved with having 6 clones on one hard drive (as I have had) boggle
>> the mind. I suspect that the re-naming problem, if it has occurred for you,
>> involves some other mechanism. Have you always removed the "parent"
>> OS from view before starting up the clone for its first run? Only in such
>> a case have I ever seen anomalies of any form whatsoever.
>>
>> *TimDaniels*
>>
>>
>> "John John (MVP)" wrote:
>>
>>>The problem is that the drive letters are assigned based on disk and
>>>partition signatures and that the signatures and letter assignments are
>>>recorded in the registry. When the clone is booted it will respect the
>>>letter assignments in the registry and the new (cloned) Windows
>>>installation will not keep its originally assigned drive letter, the C drive
>>>letter will be assigned to the parent drive so it won't be available for
>>>the clone.
>>>
>>>John
>>>
>>>
>>>Timothy Daniels wrote:
>>>
>>>
>>>>You prove my case - that the letter name by which the "parent"
>>>>Windows OS knows its own partition (assigned to it by the
>>>>installer) will be the name that the clone will always call its own
>>>>partition (when it is running, naturally). Because a clone contains
>>>>exactly the same information, it too will call its own partition by
>>>>the same name (when it - the clone - is running). So the two OSes
>>>>(the "parent" and its clone) will refer to their own partitions by the
>>>>same name, which is no problem because they won't be running
>>>>at the time, and who but the running OS cares what each partition
>>>>is called, anyway? Of course, this implies that some or all partitions
>>>>will be renamed according to which OS is running, but as long as
>>>>there are no shortcuts that include the name of another partition,
>>>>there will be no problem.
>>>>
>>>>You mention a case in which a clone would assign itself a name
>>>>other than that of its "parent" OS. How could that happen? If
>>>>that happened, it would immediately no longer be a clone. What
>>>>would change it from a copy of its "parent" to some errant child
>>>>that decided to rename itself? And since it really doesn't know
>>>>that it's a clone, what would cause an OS to spontaneously rename
>>>>its partition?
>>>>
>>>>*TimDaniels*
>>>>
>>>>"John John (MVP)" wrote:
>>>>
>>>>
>>>>>If he cloned an installation residing on drive "C" to another partition
>>>>>on the disk and if the clone adopts another drive letter when it boots,
>>>>>lets say drive "D" for example, then there will be serious problems!
>>>>>The Windows installation must *always* retain the drive letter onto
>>>>>which it was installed, if your Windows installation is installed on "C:"
>>>>>do a search in your registry for C: and the importance of maintaining
>>>>>the installation drive letter will become clearly apparent, shortcuts
>>>>>will be the least of your problems if the Windows volume is assigned
>>>>>a different drive letter!
>>>>>
>>>>>John
>>>>>
>>>>>
>>>>>Timothy Daniels wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Of what importance is the drive letter that a Windows OS uses
>>>>>>while it is running? As long as there are no shorcuts which include
>>>>>>the name of a partition, there will be no problem. Are you
>>>>>>assuming that there are such shortcuts?
>>>>>>
>>>>>>*TimDaniels*
>>>>>>
>>>>>>"John John (MVP)" wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Has the cloned installation retained the same drive letter as the
>>>>>>>parent? I suspect that it hasn't and that this is the cause of your
>>>>>>>problems. Boot to the parent installation and at the Command
>>>>>>>Prompt issue:
>>>>>>>
>>>>>>>set systemroot
>>>>>>>
>>>>>>>Then boot to the clone and issue the same command, both
>>>>>>>should return the same drive letter, if not that is the cause of
>>>>>>>your problems.
>>>>>>>
>>>>>>>John
>>>>>>>
>>>>>>>Dennis Wilson wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>I used Partition Magic to clone the partition containing my
>>>>>>>>new Windows XP installation. Both are on the same hard
>>>>>>>>drive, and they're the only two partitions on it. Basically,
>>>>>>>>this just gives me a backup of my system which I can use to
>>>>>>>>copy back over the original if the original (the one on
>>>>>>>>Partion 1) gets corrupted. I keep Partition 2 marked "hidden"
>>>>>>>>and therefore inacessible most of the time, though I will
>>>>>>>>occasionally use BootMagic to boot into Partition 2 to copy
>>>>>>>>a deleted file or something. This backup method worked
>>>>>>>>perfectly for me for all the years I've used it. Until now.
>>>>>>>>I recently built a new computer, and as usual I installed
>>>>>>>>Windows and then all my apps and then cloned the entire
>>>>>>>>"install" onto a new partition. But after the cloning, many of
>>>>>>>>my apps needed to have their configurations redone, and
>>>>>>>>those that require "activation" need to be RE-activated. It's
>>>>>>>>as if my apps can't find the registry. Yet the drive letter
>>>>>>>>assignments all seem right, and I believe the boot.ini files
>>>>>>>>are written correctly as well. The one on partition 1 reads:
>>>>>>>>[boot loader]
>>>>>>>>timeout=0
>>>>>>>>default=multi(0)disk(0)rdisk(0)partition(1 )\WINDOWS
>>>>>>>>[operating systems]
>>>>>>>>multi(0)disk(0)rdisk(0)partition(1)\WINDOW S="Windows XP 1"
>>>>>>>>multi(0)disk(0)rdisk(0)partition(2)\WINDOW S="Windows XP 2"
>>>>>>>>
>>>>>>>>The one on Partition 2 is the same, except the [boot loader]
>>>>>>>>line reads:
>>>>>>>>
>>>>>>>>default=multi(0)disk(0)rdisk(0)partition(2 )\WINDOWS
>>>>>>>>
>>>>>>>>The problem was the same on both partitions, and the result
>>>>>>>>was the same when I wiped the drive and reinstalled everything
>>>>>>>>from scratch. Needless to say, I can't figure out the reason for
>>>>>>>>this behavior. The only difference between this machine and
>>>>>>>>all the other PCs I've built is that this is the first one that has
>>>>>>>>SATA hard drives instead of IDE; the only IDE device on this
>>>>>>>>system is an HP DVD+/-R recorder. Can anyone suggest
>>>>>>>>what I might have overlooked, or what I can do to get my
>>>>>>>>apps able to read their config info again?
>>>>>>>>
>>>>>>>>Thanks.
>>>>>>>>** Posted from http://www.teranews.com **
>>>>>>
>>>>>>
>>
That can happen when the "parent" is visible to the clone the first time
it is booted, that is why you tell users to make sure that the "parent"
disk is disconnected when the clone is booted the first time. If the
parent isn't present then there are no problems, but if the original
drive is still present when the clone is booted and if the information
in the MountedDevices key is valid then due to the Mount Manager's
persistent drive letter assignments the old drive will retain its drive
letters and the new cloned drive will be assigned other letters.
If you reread the original post again you will remember that the OP
cloned the installation to another partition on the same disk and that
he didn't take appropriate measures to avoid this drive lettering snafu,
when he boots the clone it (most likely, but he didn't confirm) adopts a
drive letter other than C: and it is causing problems because a Windows
installation must always maintain the drive letter it was assigned when
it was installed. The OP can easily fix this problem without changing
the active partition status or without hiding the parent partition, he
simply needs to edit the drive letter information in the clone's
MountedDevices key and give the C: letter assignment to the cloned
partition and assign another letter to the active partition.
John
Timothy Daniels wrote:
> Is this consistent behavior? It's strange that your procedure leads to
> this, and my procedure has not in 4 years of cloning. In that period
> of time, I have *never* seen this to occur. In my experience, the
> clone has *always* referred to its own partition by the same letter
> name as its "parent" did, and my experience has been with Drive
> Image, Ghost, and most recently with Casper. In the past, we may
> have had discussions about *why* you observe what you do, but
> not about why our observations differ so consistently. I think that
> it may be due to the procedures or the utilities that we use to do the
> cloning. Do you clone entire hard drives, or do you clone single
> partitions? (I only clone single partitions that contain the OS.)
> What cloning utility did you use when this re-naming occurred?
>
> *TimDaniels*
>
>
> "John John (MVP)" wrote:
>
>>Yes! Many times! The clone has the same MountedDevices key and information
>>and when the Windows installation is booted the information in the key is
>>*always* respected and the drive letters will be assigned accordinly. It's
>>nothing new, we have had lengthy discussions about this in the past.
>>
>>John
>>
>>Timothy Daniels wrote:
>>
>>
>>>Have you ever seen this to occur? In about 4 years of making clones
>>>on hard drives, I have never seen a clone rename its partition - it always
>>>uses the same name that its "parent" OS used to refer to its own partition.
>>>If drive letters were assigned based on disk and partition signatures, why
>>>does the installer always choose "C:" if that is available? When you say
>>>"When the clone is booted it will respect the letter assignments in the
>>>registry...", I assume that you mean its own (the clone's) registry, as it
>>>is unlikely to be reading any other registry. So why would the clone not
>>>keep and "respect" what it finds in its own registry? After all, it doesn't
>>>know that it is a clone. And if it were to rename its own partition, how
>>>would it know what to name the partition that contains its "parent"?
>>>Wouldn't it have to first do a search for any other Windows OSes in the
>>>system and then to read the registries of each one to learn what those
>>>OSes call their own partitions so as not to have a conflict? The problems
>>>involved with having 6 clones on one hard drive (as I have had) boggle
>>>the mind. I suspect that the re-naming problem, if it has occurred for you,
>>>involves some other mechanism. Have you always removed the "parent"
>>>OS from view before starting up the clone for its first run? Only in such
>>>a case have I ever seen anomalies of any form whatsoever.
>>>
>>>*TimDaniels*
>>>
>>>
>>>"John John (MVP)" wrote:
>>>
>>>
>>>>The problem is that the drive letters are assigned based on disk and
>>>>partition signatures and that the signatures and letter assignments are
>>>>recorded in the registry. When the clone is booted it will respect the
>>>>letter assignments in the registry and the new (cloned) Windows
>>>>installation will not keep its originally assigned drive letter, the C drive
>>>>letter will be assigned to the parent drive so it won't be available for
>>>>the clone.
>>>>
>>>>John
>>>>
>>>>
>>>>Timothy Daniels wrote:
>>>>
>>>>
>>>>
>>>>>You prove my case - that the letter name by which the "parent"
>>>>>Windows OS knows its own partition (assigned to it by the
>>>>>installer) will be the name that the clone will always call its own
>>>>>partition (when it is running, naturally). Because a clone contains
>>>>>exactly the same information, it too will call its own partition by
>>>>>the same name (when it - the clone - is running). So the two OSes
>>>>>(the "parent" and its clone) will refer to their own partitions by the
>>>>>same name, which is no problem because they won't be running
>>>>>at the time, and who but the running OS cares what each partition
>>>>>is called, anyway? Of course, this implies that some or all partitions
>>>>>will be renamed according to which OS is running, but as long as
>>>>>there are no shortcuts that include the name of another partition,
>>>>>there will be no problem.
>>>>>
>>>>>You mention a case in which a clone would assign itself a name
>>>>>other than that of its "parent" OS. How could that happen? If
>>>>>that happened, it would immediately no longer be a clone. What
>>>>>would change it from a copy of its "parent" to some errant child
>>>>>that decided to rename itself? And since it really doesn't know
>>>>>that it's a clone, what would cause an OS to spontaneously rename
>>>>>its partition?
>>>>>
>>>>>*TimDaniels*
>>>>>
>>>>>"John John (MVP)" wrote:
>>>>>
>>>>>
>>>>>
>>>>>>If he cloned an installation residing on drive "C" to another partition
>>>>>>on the disk and if the clone adopts another drive letter when it boots,
>>>>>>lets say drive "D" for example, then there will be serious problems!
>>>>>>The Windows installation must *always* retain the drive letter onto
>>>>>>which it was installed, if your Windows installation is installed on "C:"
>>>>>>do a search in your registry for C: and the importance of maintaining
>>>>>>the installation drive letter will become clearly apparent, shortcuts
>>>>>>will be the least of your problems if the Windows volume is assigned
>>>>>>a different drive letter!
>>>>>>
>>>>>>John
>>>>>>
>>>>>>
>>>>>>Timothy Daniels wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Of what importance is the drive letter that a Windows OS uses
>>>>>>>while it is running? As long as there are no shorcuts which include
>>>>>>>the name of a partition, there will be no problem. Are you
>>>>>>>assuming that there are such shortcuts?
>>>>>>>
>>>>>>>*TimDaniels*
>>>>>>>
>>>>>>>"John John (MVP)" wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Has the cloned installation retained the same drive letter as the
>>>>>>>>parent? I suspect that it hasn't and that this is the cause of your
>>>>>>>>problems. Boot to the parent installation and at the Command
>>>>>>>>Prompt issue:
>>>>>>>>
>>>>>>>>set systemroot
>>>>>>>>
>>>>>>>>Then boot to the clone and issue the same command, both
>>>>>>>>should return the same drive letter, if not that is the cause of
>>>>>>>>your problems.
>>>>>>>>
>>>>>>>>John
>>>>>>>>
>>>>>>>>Dennis Wilson wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>I used Partition Magic to clone the partition containing my
>>>>>>>>>new Windows XP installation. Both are on the same hard
>>>>>>>>>drive, and they're the only two partitions on it. Basically,
>>>>>>>>>this just gives me a backup of my system which I can use to
>>>>>>>>>copy back over the original if the original (the one on
>>>>>>>>>Partion 1) gets corrupted. I keep Partition 2 marked "hidden"
>>>>>>>>>and therefore inacessible most of the time, though I will
>>>>>>>>>occasionally use BootMagic to boot into Partition 2 to copy
>>>>>>>>>a deleted file or something. This backup method worked
>>>>>>>>>perfectly for me for all the years I've used it. Until now.
>>>>>>>>>I recently built a new computer, and as usual I installed
>>>>>>>>>Windows and then all my apps and then cloned the entire
>>>>>>>>>"install" onto a new partition. But after the cloning, many of
>>>>>>>>>my apps needed to have their configurations redone, and
>>>>>>>>>those that require "activation" need to be RE-activated. It's
>>>>>>>>>as if my apps can't find the registry. Yet the drive letter
>>>>>>>>>assignments all seem right, and I believe the boot.ini files
>>>>>>>>>are written correctly as well. The one on partition 1 reads:
>>>>>>>>>[boot loader]
>>>>>>>>>timeout=0
>>>>>>>>>default=multi(0)disk(0)rdisk(0)partition( 1)\WINDOWS
>>>>>>>>>[operating systems]
>>>>>>>>>multi(0)disk(0)rdisk(0)partition(1)\WINDO WS="Windows XP 1"
>>>>>>>>>multi(0)disk(0)rdisk(0)partition(2)\WINDO WS="Windows XP 2"
>>>>>>>>>
>>>>>>>>>The one on Partition 2 is the same, except the [boot loader]
>>>>>>>>>line reads:
>>>>>>>>>
>>>>>>>>>default=multi(0)disk(0)rdisk(0)partition( 2)\WINDOWS
>>>>>>>>>
>>>>>>>>>The problem was the same on both partitions, and the result
>>>>>>>>>was the same when I wiped the drive and reinstalled everything
>>>>>>>>
>>>>>>>>>from scratch. Needless to say, I can't figure out the reason for
>>>>>>>>
>>>>>>>>>this behavior. The only difference between this machine and
>>>>>>>>>all the other PCs I've built is that this is the first one that has
>>>>>>>>>SATA hard drives instead of IDE; the only IDE device on this
>>>>>>>>>system is an HP DVD+/-R recorder. Can anyone suggest
>>>>>>>>>what I might have overlooked, or what I can do to get my
>>>>>>>>>apps able to read their config info again?
>>>>>>>>>
>>>>>>>>>Thanks.
>>>>>>>>>** Posted from http://www.teranews.com **
>>>>>>>
>>>>>>>
>
The implication is, then, that both you and the OP made the error
of letting the clone, on its first-ever run, see its "parent" OS - as I
suggested to the OP as being the cause of his problem. The OP,
while usually keeping the clone in a "hidden" partition, occasionaly
started up the clone in order to move a file to or from the clone.
The first time that he did this could have led to the re-naming of the
partition. The OP really didn't need to start up the clone for that
purpose, as the running OS could just as easily have read or written
a file in the clone's file structure (as well as any other data partition)
without starting up the clone. Alternately, using his current skillset,
the OP could have "hidden" the "parent" OS's partition after he
made the clone and then started up the clone for its first run, and
thus have prevented the clone from seeing its "parent" OS during
that first startup.
As for editing the registry to avoid the re-naming problem, could
you post detailed steps to do that, John? I'd like to file them away
for some time when I'm brave and can afford to lose a clone to
experimentation. :-)
*TimDaniels*
"John John (MVP)" wrote:
> That can happen when the "parent" is visible to the clone the first time it is
> booted, that is why you tell users to make sure that the "parent" disk is
> disconnected when the clone is booted the first time. If the parent isn't
> present then there are no problems, but if the original drive is still present
> when the clone is booted and if the information in the MountedDevices key is
> valid then due to the Mount Manager's persistent drive letter assignments the
> old drive will retain its drive letters and the new cloned drive will be
> assigned other letters.
>
> If you reread the original post again you will remember that the OP cloned the
> installation to another partition on the same disk and that he didn't take
> appropriate measures to avoid this drive lettering snafu, when he boots the
> clone it (most likely, but he didn't confirm) adopts a drive letter other than
> C: and it is causing problems because a Windows installation must always
> maintain the drive letter it was assigned when it was installed. The OP can
> easily fix this problem without changing the active partition status or
> without hiding the parent partition, he simply needs to edit the drive letter
> information in the clone's MountedDevices key and give the C: letter
> assignment to the cloned partition and assign another letter to the active
> partition.
>
> John
>
> Timothy Daniels wrote:
>
>> Is this consistent behavior? It's strange that your procedure leads to
>> this, and my procedure has not in 4 years of cloning. In that period
>> of time, I have *never* seen this to occur. In my experience, the
>> clone has *always* referred to its own partition by the same letter
>> name as its "parent" did, and my experience has been with Drive
>> Image, Ghost, and most recently with Casper. In the past, we may
>> have had discussions about *why* you observe what you do, but
>> not about why our observations differ so consistently. I think that
>> it may be due to the procedures or the utilities that we use to do the
>> cloning. Do you clone entire hard drives, or do you clone single
>> partitions? (I only clone single partitions that contain the OS.)
>> What cloning utility did you use when this re-naming occurred?
>>
>> *TimDaniels*
>>
>>
>> "John John (MVP)" wrote:
>>
>>>Yes! Many times! The clone has the same MountedDevices key
>>>and information and when the Windows installation is booted the
>>>information in the key is *always* respected and the drive letters
>>>will be assigned accordinly. It's nothing new, we have had lengthy
>>>discussions about this in the past.
>>>
>>>John
>>>
>>>Timothy Daniels wrote:
>>>
>>>
>>>>Have you ever seen this to occur? In about 4 years of making clones
>>>>on hard drives, I have never seen a clone rename its partition - it always
>>>>uses the same name that its "parent" OS used to refer to its own partition.
>>>>If drive letters were assigned based on disk and partition signatures, why
>>>>does the installer always choose "C:" if that is available? When you say
>>>>"When the clone is booted it will respect the letter assignments in the
>>>>registry...", I assume that you mean its own (the clone's) registry, as it
>>>>is unlikely to be reading any other registry. So why would the clone not
>>>>keep and "respect" what it finds in its own registry? After all, it doesn't
>>>>know that it is a clone. And if it were to rename its own partition, how
>>>>would it know what to name the partition that contains its "parent"?
>>>>Wouldn't it have to first do a search for any other Windows OSes in the
>>>>system and then to read the registries of each one to learn what those
>>>>OSes call their own partitions so as not to have a conflict? The problems
>>>>involved with having 6 clones on one hard drive (as I have had) boggle
>>>>the mind. I suspect that the re-naming problem, if it has occurred for you,
>>>>involves some other mechanism. Have you always removed the "parent"
>>>>OS from view before starting up the clone for its first run? Only in such
>>>>a case have I ever seen anomalies of any form whatsoever.
>>>>
>>>>*TimDaniels*
>>>>
>>>>
>>>>"John John (MVP)" wrote:
>>>>
>>>>
>>>>>The problem is that the drive letters are assigned based on disk and
>>>>>partition signatures and that the signatures and letter assignments are
>>>>>recorded in the registry. When the clone is booted it will respect the
>>>>>letter assignments in the registry and the new (cloned) Windows
>>>>>installation will not keep its originally assigned drive letter, the C
>>>>>drive
>>>>>letter will be assigned to the parent drive so it won't be available for
>>>>>the clone.
>>>>>
>>>>>John
>>>>>
>>>>>
>>>>>Timothy Daniels wrote:
>>>>>
>>>>>
>>>>>
>>>>>>You prove my case - that the letter name by which the "parent"
>>>>>>Windows OS knows its own partition (assigned to it by the
>>>>>>installer) will be the name that the clone will always call its own
>>>>>>partition (when it is running, naturally). Because a clone contains
>>>>>>exactly the same information, it too will call its own partition by
>>>>>>the same name (when it - the clone - is running). So the two OSes
>>>>>>(the "parent" and its clone) will refer to their own partitions by the
>>>>>>same name, which is no problem because they won't be running
>>>>>>at the time, and who but the running OS cares what each partition
>>>>>>is called, anyway? Of course, this implies that some or all partitions
>>>>>>will be renamed according to which OS is running, but as long as
>>>>>>there are no shortcuts that include the name of another partition,
>>>>>>there will be no problem.
>>>>>>
>>>>>>You mention a case in which a clone would assign itself a name
>>>>>>other than that of its "parent" OS. How could that happen? If
>>>>>>that happened, it would immediately no longer be a clone. What
>>>>>>would change it from a copy of its "parent" to some errant child
>>>>>>that decided to rename itself? And since it really doesn't know
>>>>>>that it's a clone, what would cause an OS to spontaneously rename
>>>>>>its partition?
>>>>>>
>>>>>>*TimDaniels*
>>>>>>
>>>>>>"John John (MVP)" wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>If he cloned an installation residing on drive "C" to another partition
>>>>>>>on the disk and if the clone adopts another drive letter when it boots,
>>>>>>>lets say drive "D" for example, then there will be serious problems!
>>>>>>>The Windows installation must *always* retain the drive letter onto
>>>>>>>which it was installed, if your Windows installation is installed on "C:"
>>>>>>>do a search in your registry for C: and the importance of maintaining
>>>>>>>the installation drive letter will become clearly apparent, shortcuts
>>>>>>>will be the least of your problems if the Windows volume is assigned
>>>>>>>a different drive letter!
>>>>>>>
>>>>>>>John
>>>>>>>
>>>>>>>
>>>>>>>Timothy Daniels wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Of what importance is the drive letter that a Windows OS uses
>>>>>>>>while it is running? As long as there are no shorcuts which include
>>>>>>>>the name of a partition, there will be no problem. Are you
>>>>>>>>assuming that there are such shortcuts?
>>>>>>>>
>>>>>>>>*TimDaniels*
>>>>>>>>
>>>>>>>>"John John (MVP)" wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Has the cloned installation retained the same drive letter as the
>>>>>>>>>parent? I suspect that it hasn't and that this is the cause of your
>>>>>>>>>problems. Boot to the parent installation and at the Command
>>>>>>>>>Prompt issue:
>>>>>>>>>
>>>>>>>>>set systemroot
>>>>>>>>>
>>>>>>>>>Then boot to the clone and issue the same command, both
>>>>>>>>>should return the same drive letter, if not that is the cause of
>>>>>>>>>your problems.
>>>>>>>>>
>>>>>>>>>John
>>>>>>>>>
>>>>>>>>>Dennis Wilson wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>I used Partition Magic to clone the partition containing my
>>>>>>>>>>new Windows XP installation. Both are on the same hard
>>>>>>>>>>drive, and they're the only two partitions on it. Basically,
>>>>>>>>>>this just gives me a backup of my system which I can use to
>>>>>>>>>>copy back over the original if the original (the one on
>>>>>>>>>>Partion 1) gets corrupted. I keep Partition 2 marked "hidden"
>>>>>>>>>>and therefore inacessible most of the time, though I will
>>>>>>>>>>occasionally use BootMagic to boot into Partition 2 to copy
>>>>>>>>>>a deleted file or something. This backup method worked
>>>>>>>>>>perfectly for me for all the years I've used it. Until now.
>>>>>>>>>>I recently built a new computer, and as usual I installed
>>>>>>>>>>Windows and then all my apps and then cloned the entire
>>>>>>>>>>"install" onto a new partition. But after the cloning, many of
>>>>>>>>>>my apps needed to have their configurations redone, and
>>>>>>>>>>those that require "activation" need to be RE-activated. It's
>>>>>>>>>>as if my apps can't find the registry. Yet the drive letter
>>>>>>>>>>assignments all seem right, and I believe the boot.ini files
>>>>>>>>>>are written correctly as well. The one on partition 1 reads:
>>>>>>>>>>[boot loader]
>>>>>>>>>>timeout=0
>>>>>>>>>>default=multi(0)disk(0)rdisk(0)partition (1)\WINDOWS
>>>>>>>>>>[operating systems]
>>>>>>>>>>multi(0)disk(0)rdisk(0)partition(1)\WIND OWS="Windows XP 1"
>>>>>>>>>>multi(0)disk(0)rdisk(0)partition(2)\WIND OWS="Windows XP 2"
>>>>>>>>>>
>>>>>>>>>>The one on Partition 2 is the same, except the [boot loader]
>>>>>>>>>>line reads:
>>>>>>>>>>
>>>>>>>>>>default=multi(0)disk(0)rdisk(0)partition (2)\WINDOWS
>>>>>>>>>>
>>>>>>>>>>The problem was the same on both partitions, and the result
>>>>>>>>>>was the same when I wiped the drive and reinstalled everything
>>>>>>>>>
>>>>>>>>>>from scratch. Needless to say, I can't figure out the reason for
>>>>>>>>>
>>>>>>>>>>this behavior. The only difference between this machine and
>>>>>>>>>>all the other PCs I've built is that this is the first one that has
>>>>>>>>>>SATA hard drives instead of IDE; the only IDE device on this
>>>>>>>>>>system is an HP DVD+/-R recorder. Can anyone suggest
>>>>>>>>>>what I might have overlooked, or what I can do to get my
>>>>>>>>>>apps able to read their config info again?
>>>>>>>>>>
>>>>>>>>>>Thanks.
>>>>>>>>>>** Posted from http://www.teranews.com **
>>>>>>>>
>>>>>>>>
>>
>
At times it is just as easy or easier to simply edit the registry or use
other methods like a W98 boot disk and fdisk /mbr than it is to hide or
disconnect disks. In the case of a clone on another partition on the
same disk hiding partitions can be more of a hassle (you need third
party tools) than to simply edit the drive letters at the registry.
To ensure that a clone on another partition on the same disk can be
booted to the same drive letter without hiding partitions and without
changing the active partition you can remotely edit the clone's letter
assignment at the MountedDevices key. For example, if you clone the
installation on the C: drive to the D: partition, edit the clone's
registry and switch the letters. It is just an adaptation of the
instructions here:
To edit the clone's registry while booted to the original (remotely edit
the registry) follow the simple instructions here: http://www.rwin.ch/xp-live/regedit.htm
John
Timothy Daniels wrote:
> The implication is, then, that both you and the OP made the error
> of letting the clone, on its first-ever run, see its "parent" OS - as I
> suggested to the OP as being the cause of his problem. The OP,
> while usually keeping the clone in a "hidden" partition, occasionaly
> started up the clone in order to move a file to or from the clone.
> The first time that he did this could have led to the re-naming of the
> partition. The OP really didn't need to start up the clone for that
> purpose, as the running OS could just as easily have read or written
> a file in the clone's file structure (as well as any other data partition)
> without starting up the clone. Alternately, using his current skillset,
> the OP could have "hidden" the "parent" OS's partition after he
> made the clone and then started up the clone for its first run, and
> thus have prevented the clone from seeing its "parent" OS during
> that first startup.
>
> As for editing the registry to avoid the re-naming problem, could
> you post detailed steps to do that, John? I'd like to file them away
> for some time when I'm brave and can afford to lose a clone to
> experimentation. :-)
>
> *TimDaniels*
>
> "John John (MVP)" wrote:
>
>>That can happen when the "parent" is visible to the clone the first time it is
>>booted, that is why you tell users to make sure that the "parent" disk is
>>disconnected when the clone is booted the first time. If the parent isn't
>>present then there are no problems, but if the original drive is still present
>>when the clone is booted and if the information in the MountedDevices key is
>>valid then due to the Mount Manager's persistent drive letter assignments the
>>old drive will retain its drive letters and the new cloned drive will be
>>assigned other letters.
>>
>>If you reread the original post again you will remember that the OP cloned the
>>installation to another partition on the same disk and that he didn't take
>>appropriate measures to avoid this drive lettering snafu, when he boots the
>>clone it (most likely, but he didn't confirm) adopts a drive letter other than
>>C: and it is causing problems because a Windows installation must always
>>maintain the drive letter it was assigned when it was installed. The OP can
>>easily fix this problem without changing the active partition status or
>>without hiding the parent partition, he simply needs to edit the drive letter
>>information in the clone's MountedDevices key and give the C: letter
>>assignment to the cloned partition and assign another letter to the active
>>partition.
>>
>>John
>>
>>Timothy Daniels wrote:
>>
>>
>>>Is this consistent behavior? It's strange that your procedure leads to
>>>this, and my procedure has not in 4 years of cloning. In that period
>>>of time, I have *never* seen this to occur. In my experience, the
>>>clone has *always* referred to its own partition by the same letter
>>>name as its "parent" did, and my experience has been with Drive
>>>Image, Ghost, and most recently with Casper. In the past, we may
>>>have had discussions about *why* you observe what you do, but
>>>not about why our observations differ so consistently. I think that
>>>it may be due to the procedures or the utilities that we use to do the
>>>cloning. Do you clone entire hard drives, or do you clone single
>>>partitions? (I only clone single partitions that contain the OS.)
>>>What cloning utility did you use when this re-naming occurred?
>>>
>>>*TimDaniels*
>>>
>>>
>>>"John John (MVP)" wrote:
>>>
>>>
>>>>Yes! Many times! The clone has the same MountedDevices key
>>>>and information and when the Windows installation is booted the
>>>>information in the key is *always* respected and the drive letters
>>>>will be assigned accordinly. It's nothing new, we have had lengthy
>>>>discussions about this in the past.
>>>>
>>>>John
>>>>
>>>>Timothy Daniels wrote:
>>>>
>>>>
>>>>
>>>>>Have you ever seen this to occur? In about 4 years of making clones
>>>>>on hard drives, I have never seen a clone rename its partition - it always
>>>>>uses the same name that its "parent" OS used to refer to its own partition.
>>>>>If drive letters were assigned based on disk and partition signatures, why
>>>>>does the installer always choose "C:" if that is available? When you say
>>>>>"When the clone is booted it will respect the letter assignments in the
>>>>>registry...", I assume that you mean its own (the clone's) registry, as it
>>>>>is unlikely to be reading any other registry. So why would the clone not
>>>>>keep and "respect" what it finds in its own registry? After all, it doesn't
>>>>>know that it is a clone. And if it were to rename its own partition, how
>>>>>would it know what to name the partition that contains its "parent"?
>>>>>Wouldn't it have to first do a search for any other Windows OSes in the
>>>>>system and then to read the registries of each one to learn what those
>>>>>OSes call their own partitions so as not to have a conflict? The problems
>>>>>involved with having 6 clones on one hard drive (as I have had) boggle
>>>>>the mind. I suspect that the re-naming problem, if it has occurred for you,
>>>>>involves some other mechanism. Have you always removed the "parent"
>>>>>OS from view before starting up the clone for its first run? Only in such
>>>>>a case have I ever seen anomalies of any form whatsoever.
>>>>>
>>>>>*TimDaniels*
>>>>>
>>>>>
>>>>>"John John (MVP)" wrote:
>>>>>
>>>>>
>>>>>
>>>>>>The problem is that the drive letters are assigned based on disk and
>>>>>>partition signatures and that the signatures and letter assignments are
>>>>>>recorded in the registry. When the clone is booted it will respect the
>>>>>>letter assignments in the registry and the new (cloned) Windows
>>>>>>installation will not keep its originally assigned drive letter, the C
>>>>>>drive
>>>>>>letter will be assigned to the parent drive so it won't be available for
>>>>>>the clone.
>>>>>>
>>>>>>John
>>>>>>
>>>>>>
>>>>>>Timothy Daniels wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>You prove my case - that the letter name by which the "parent"
>>>>>>>Windows OS knows its own partition (assigned to it by the
>>>>>>>installer) will be the name that the clone will always call its own
>>>>>>>partition (when it is running, naturally). Because a clone contains
>>>>>>>exactly the same information, it too will call its own partition by
>>>>>>>the same name (when it - the clone - is running). So the two OSes
>>>>>>>(the "parent" and its clone) will refer to their own partitions by the
>>>>>>>same name, which is no problem because they won't be running
>>>>>>>at the time, and who but the running OS cares what each partition
>>>>>>>is called, anyway? Of course, this implies that some or all partitions
>>>>>>>will be renamed according to which OS is running, but as long as
>>>>>>>there are no shortcuts that include the name of another partition,
>>>>>>>there will be no problem.
>>>>>>>
>>>>>>>You mention a case in which a clone would assign itself a name
>>>>>>>other than that of its "parent" OS. How could that happen? If
>>>>>>>that happened, it would immediately no longer be a clone. What
>>>>>>>would change it from a copy of its "parent" to some errant child
>>>>>>>that decided to rename itself? And since it really doesn't know
>>>>>>>that it's a clone, what would cause an OS to spontaneously rename
>>>>>>>its partition?
>>>>>>>
>>>>>>>*TimDaniels*
>>>>>>>
>>>>>>>"John John (MVP)" wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>If he cloned an installation residing on drive "C" to another partition
>>>>>>>>on the disk and if the clone adopts another drive letter when it boots,
>>>>>>>>lets say drive "D" for example, then there will be serious problems!
>>>>>>>>The Windows installation must *always* retain the drive letter onto
>>>>>>>>which it was installed, if your Windows installation is installed on "C:"
>>>>>>>>do a search in your registry for C: and the importance of maintaining
>>>>>>>>the installation drive letter will become clearly apparent, shortcuts
>>>>>>>>will be the least of your problems if the Windows volume is assigned
>>>>>>>>a different drive letter!
>>>>>>>>
>>>>>>>>John
>>>>>>>>
>>>>>>>>
>>>>>>>>Timothy Daniels wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Of what importance is the drive letter that a Windows OS uses
>>>>>>>>>while it is running? As long as there are no shorcuts which include
>>>>>>>>>the name of a partition, there will be no problem. Are you
>>>>>>>>>assuming that there are such shortcuts?
>>>>>>>>>
>>>>>>>>>*TimDaniels*
>>>>>>>>>
>>>>>>>&g
Re: Programs not working right after cloning 