Programs not working right after cloning [Archive]

Timothy Daniels[_3_]

August 4th 08, 01:50 AM

How is something "cloned from C:" going to "end up on D:"?

*TimDaniels*

"Hula Baloo" wrote:
> Oh HO, my friend. The drive letter is in many, many places in the registry.
> If you clone something from C: and it ends up on D: or anything other than C:,
> Windows is going to choke because many things use the registry to find out
> where things are stored.
>
> 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="Windows XP 1"
>>>> multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="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)\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 **
>>
>>

John John (MVP)

August 4th 08, 03:12 PM

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="Windows XP 1"
>>> multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="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)\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 **
>
>
>

John John (MVP)

August 4th 08, 03:24 PM

It's the same kind of thing that can sometimes happen when the parent
drive is left plugged in when the clone is booted for the first time,
you already know all of that, Tim. The problem may be more difficult to
circumvent when cloning to other partitions on the same disk.

John

Timothy Daniels wrote:

> How is something "cloned from C:" going to "end up on D:"?
>
> *TimDaniels*
>
> "Hula Baloo" wrote:
>
>> Oh HO, my friend. The drive letter is in many, many places in the registry.
>>If you clone something from C: and it ends up on D: or anything other than C:,
>>Windows is going to choke because many things use the registry to find out
>>where things are stored.
>>
>>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="Windows XP 1"
>>>>> multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="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)\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 **
>>>
>>>
>
>

AJR

August 4th 08, 04:22 PM

When restoring a "Clone" you have the option of restoring to the original
loction (C) or an alternate (D).

Any good backup utility will not let you set as the target the same drive
that contains the partition your backing up or cloning - or at least warn
you that it is not advisable .

Note the following from the original post: "...use BootMagic to boot into
Partition 2 to copy a deleted file or something. ..." and from boot.ini "...
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)WINDOWS="Windows XP 1"
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows XP 2"...."

Clones are usually compressed images - recovering individual files requires
the clone utility or mounting the image via a virtual HD -not BootMagic .

The boot.ini - and use of BootMagic - indicate a dual boot scene - can
"cloning" with Partition Magic create a dual boot setup or is it possible
the first partition was copied and not cloned?

"Timothy Daniels" > wrote in message
...
> How is something "cloned from C:" going to "end up on D:"?
>
> *TimDaniels*
>
> "Hula Baloo" wrote:
>> Oh HO, my friend. The drive letter is in many, many places in the
>> registry. If you clone something from C: and it ends up on D: or anything
>> other than C:, Windows is going to choke because many things use the
>> registry to find out where things are stored.
>>
>> 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="Windows XP 1"
>>>>> multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="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)\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 **
>>>
>>>
>
>

Timothy Daniels[_3_]

August 5th 08, 12:17 AM

In most NGs, perhaps most forums as well, "clone" refers to an
exact byte-for-byte copy of the original partition, and it resides
on a hard drive in the same bootable form as its "parent" OS.
An "image" refers to a *file* that contains all the information
necessary to rebuild a replica of the original partition. Because
an image is just a data file, it can be compressed using various
algorithms and put on something other that a hard drive storage
medium (such as CDs/DVDs/USB "thumb" drives/etc.), but it
requires the extra step of "restoration" to return it to a bootable
form on a hard drive. Beacause a clone is an exact copy of all
that is in a partition - even in the registry, in the case of a Windows
OS - I can't see how that copy would have its registry contents
changed so that it would thereafter refer to its own partition by
any other letter name than that which its "parent" OS had. If
does, indeed, occasionally happen, it's a rare and perhaps
intended occurrence.

The scenario you hypothesized involves an *image* file and its
restoration, not the making of a clone. I know that several of the
commercial backup utilities refer to their images as "clones", but
the industry has no accepted standards of nomenclature, probably
partially because many of the utilities blur the distinction between
the two forms of backup by enabling incremental backups to a
clone - previously just doable with an image file.

*TimDaniels*

"AJR" wrote:
> When restoring a "Clone" you have the option of restoring to the original
> loction (C) or an alternate (D).
>
> Any good backup utility will not let you set as the target the same drive that
> contains the partition your backing up or cloning - or at least warn you that
> it is not advisable .
>
> Note the following from the original post: "...use BootMagic to boot into
> Partition 2 to copy a deleted file or something. ..." and from boot.ini "...
> [operating systems]
> multi(0)disk(0)rdisk(0)partition(1)WINDOWS="Windows XP 1"
> multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows XP 2"...."
>
> Clones are usually compressed images - recovering individual files requires
> the clone utility or mounting the image via a virtual HD -not BootMagic .
>
> The boot.ini - and use of BootMagic - indicate a dual boot scene - can
> "cloning" with Partition Magic create a dual boot setup or is it possible the
> first partition was copied and not cloned?
>
> "Timothy Daniels" wrote:
>> How is something "cloned from C:" going to "end up on D:"?
>>
>> *TimDaniels*
>>
>> "Hula Baloo" wrote:
>>> Oh HO, my friend. The drive letter is in many, many places in the
>>> registry. If you clone something from C: and it ends up on D: or anything
>>> other than C:, Windows is going to choke because many things use the
>>> registry to find out where things are stored.
>>>
>>> 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="Windows XP 1"
>>>>>> multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="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)\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 **
>>>>
>>>>
>>
>>
>
>

Timothy Daniels[_3_]

August 5th 08, 12:28 AM

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="Windows XP 1"
>>>> multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="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)\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 **
>>
>>

John John (MVP)

August 5th 08, 01:39 AM

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="Windows XP 1"
>>>>> multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="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)\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 **
>>>
>>>
>

Timothy Daniels[_3_]

August 5th 08, 08:05 AM

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="Windows XP 1"
>>>>>> multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="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)\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 **
>>>>
>>>>
>>

John John (MVP)

August 5th 08, 11:47 AM

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="Windows XP 1"
>>>>>>> multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="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)\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 **
>>>>>
>>>>>
>
>

Timothy Daniels[_3_]

August 5th 08, 05:42 PM

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)\WINDOW S
>>>>>>>>[operating systems]
>>>>>>>>multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP 1"
>>>>>>>>multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="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)\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 **
>>>>>>
>>>>>>
>>

John John (MVP)

August 5th 08, 06:14 PM

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)\WINDOW S
>>>>>>>>>[operating systems]
>>>>>>>>>multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP 1"
>>>>>>>>>multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="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)\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 **
>>>>>>>
>>>>>>>
>

Timothy Daniels[_3_]

August 5th 08, 10:19 PM

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)\WINDOW S
>>>>>>>>>>[operating systems]
>>>>>>>>>>multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP 1"
>>>>>>>>>>multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="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)\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 **
>>>>>>>>
>>>>>>>>
>>
>

John John (MVP)

August 5th 08, 11:53 PM

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:

How to restore the system/boot drive letter in Windows
http://support.microsoft.com/kb/223188

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*
>>>>>>>>>
>>>>>>>>>"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="Windows XP 1"
>>>>>>>>>>>multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="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)\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 **
>>>>>>>>>
>>>>>>>>>
>
>

Timothy Daniels[_3_]

August 6th 08, 06:26 AM

The Microsoft article has the warning:

"Warning: Do not use the procedure that is described in this article
to change a drive on a computer where the drive letter has not
changed. If you do so, you may not be able to start your operating
system. Follow the procedure that is described in this article only
to recover from a drive letter change, not to change an existing
computer drive to something else."

Since your procedure is to *prevent* the clone from re-naming its
partition, doesn't this warning say to avoid just what you prescribe?

Given that the OP has the ability to "hide" and "un-hide" a partition,
wouldn't it be easier for him to:

1) Set the "partition()" parameter of the boot.ini file in the clone
to point to the clone's partition,
2) Unset the "active" flag in the "parent" OS's partition,
3) Hide the "parent" OS's partition,
4) Set the "active" flag in the clone OS's partition,
5) Boot the system, thereby starting up the clone for the first time,
6) Shut down the clone,
7) Unset the "active" flag in the clone's partition,
8) Hide the clone's partition (for security),
9) Set the "active" flag in the "parent" OS's partition.

Of course, with the 2 OSes on different hard drives, disconnecting
the "parent" OS's hard drive removes the need to hiding and un-
hiding its partition and to diddle the "active" flag, and if the clone's
partition has the same partition number as the "parent" OS's partition,
adjusting the clone's boot.ini file is un-necessary, so the procedure
in that case is much easier than editing the registry. Whether editing
the registry is easier for the OP in the case of the 2 OSes being on
the same disk, I'll leave that decision to the OP.

*TimDaniels*

"John John (MVP)" wrote:
> 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:
>
> How to restore the system/boot drive letter in Windows
> http://support.microsoft.com/kb/223188
>
> 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*
>>>>>>>>>>
>>>>>>>>>>"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="Windows XP 1"
>>>>>>>>>>>>multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="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)\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 **
>>>>>>>>>>
>>>>>>>>>>
>>

John John (MVP)

August 6th 08, 11:51 AM

The warning tells you that a Windows drive letter should not be changed
and editing the registry on a clone will prevent exactly that! If you
clone a Windows installation on a partition that was created and
assigned a drive letter by Windows it is assigned a different drive
letter than what the operating system has and when the clone is booted
it will use the wrong drive letter! The reason it will have the wrong
letter is because it will use the letters recorded in the MountedDevices
key and in that key the clone's partition will be recognize as a drive
other than C, doing the edit ensures that the clone has the proper drive
letter. If you think about this for two minutes, if you boot the clone
and it boots to D: then you will have to do the procedure to return the
drive assignment to C:, you can simply do it before you boot the clone
and be done with it. It is a heck of a lot easier to edit the registry
than to use third party tools and to do the bunch of steps that you
suggest, but to each his own.

John

Timothy Daniels wrote:

> The Microsoft article has the warning:
>
> "Warning: Do not use the procedure that is described in this article
> to change a drive on a computer where the drive letter has not
> changed. If you do so, you may not be able to start your operating
> system. Follow the procedure that is described in this article only
> to recover from a drive letter change, not to change an existing
> computer drive to something else."
>
> Since your procedure is to *prevent* the clone from re-naming its
> partition, doesn't this warning say to avoid just what you prescribe?
>
> Given that the OP has the ability to "hide" and "un-hide" a partition,
> wouldn't it be easier for him to:
>
> 1) Set the "partition()" parameter of the boot.ini file in the clone
> to point to the clone's partition,
> 2) Unset the "active" flag in the "parent" OS's partition,
> 3) Hide the "parent" OS's partition,
> 4) Set the "active" flag in the clone OS's partition,
> 5) Boot the system, thereby starting up the clone for the first time,
> 6) Shut down the clone,
> 7) Unset the "active" flag in the clone's partition,
> 8) Hide the clone's partition (for security),
> 9) Set the "active" flag in the "parent" OS's partition.
>
> Of course, with the 2 OSes on different hard drives, disconnecting
> the "parent" OS's hard drive removes the need to hiding and un-
> hiding its partition and to diddle the "active" flag, and if the clone's
> partition has the same partition number as the "parent" OS's partition,
> adjusting the clone's boot.ini file is un-necessary, so the procedure
> in that case is much easier than editing the registry. Whether editing
> the registry is easier for the OP in the case of the 2 OSes being on
> the same disk, I'll leave that decision to the OP.
>
> *TimDaniels*
>
> "John John (MVP)" wrote:
>
>>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:
>>
>>How to restore the system/boot drive letter in Windows
>>http://support.microsoft.com/kb/223188
>>
>>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*
>>>>>>>>>>>
>>>>>>>>>>>"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="Windows XP 1"
>>>>>>>>>>>>>multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="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)\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 **
>>>>>>>>>>>
>>>>>>>>>>>
>

Timothy Daniels[_3_]

August 6th 08, 10:05 PM

"John John (MVP)" wrote:
> if you boot the clone and it boots to D:

By this I assume you mean that it calls its own partition "D:".

> then you will have to do the procedure to return the drive
> assignment to C:, you can simply do it before you boot the
> clone and be done with it. It is a heck of a lot easier to edit
> the registry than to use third party tools and to do the bunch
> of steps that you suggest, but to each his own.
>
> John

I prefer to stay out of the registry, and a "bunch of steps"
is a result of my having listed the steps in detail. I'm sure
that editing the registry, when explained in detail, also involves
a "bunch of steps".

Since we both agree that hiding the "parent" OS from view
of the clone only needs a 3rd-party utility if the "parent" and
clone partitions are on the same disk, i.e. when the "parent"
OS can't be hidden by simply disconnecting its hard disk,
it's interesting to note that the authors of the cloning utility
"Casper", beginning with version 4.0, say that Casper can
make a clone on the same disk as the "parent" and not have
any difficulties when it's started up for the first time - even when
it can "see" its parent OS. I haven't tested this, but if it's true,
the use of Casper for cloning would always be easiest way to go.

*TimDaniels*

John John (MVP)

August 6th 08, 11:25 PM

There is no rocket science involved in this, drive letters are assigned
during the boot process, signatures and the Mount Manager's database are
at the heart of persistent drive lettering. There is nothing miraculous
about Casper, it simply modifies the clone's MountedDevices database and
switches the drive letter of the clone's drive/partition so that it
boots to the same letter as the original installation, in essence it
preemptively does the procedure in the article that I mentioned earlier,
anyone can do that manually while using any other cloning utility.

There are only three ways around the persistent drive lettering:

1- Modify the drive letters to suit in the MountedDevices key.

2- Remove all the entries in the Mount Manager's database. When Windows
is booted the IOAssignDriveLetters function will rely on a set of
predetermined rules to assign drive letters. The installation may or
may not adopt the correct drive letter, it depends on which letter you
want the installation to adopt and on how the drives are enumerated by
NTDETECT.COM.

3- Whack the disk signatures, this will automatically invalidate the
Mount Manager database and the drives will be assigned letters based on
the predetermined set of rules. Removing or disconnecting the parent
has the same effect as whacking the signature, it invalidates the Mount
Manager's database entries that deals with the now non existent
signatures, those drive letters are now available for reassignment.

John

Timothy Daniels wrote:

> "John John (MVP)" wrote:
>
>>if you boot the clone and it boots to D:
>
>
> By this I assume you mean that it calls its own partition "D:".
>
>
>>then you will have to do the procedure to return the drive
>>assignment to C:, you can simply do it before you boot the
>>clone and be done with it. It is a heck of a lot easier to edit
>>the registry than to use third party tools and to do the bunch
>>of steps that you suggest, but to each his own.
>>
>>John
>
>
> I prefer to stay out of the registry, and a "bunch of steps"
> is a result of my having listed the steps in detail. I'm sure
> that editing the registry, when explained in detail, also involves
> a "bunch of steps".
>
> Since we both agree that hiding the "parent" OS from view
> of the clone only needs a 3rd-party utility if the "parent" and
> clone partitions are on the same disk, i.e. when the "parent"
> OS can't be hidden by simply disconnecting its hard disk,
> it's interesting to note that the authors of the cloning utility
> "Casper", beginning with version 4.0, say that Casper can
> make a clone on the same disk as the "parent" and not have
> any difficulties when it's started up for the first time - even when
> it can "see" its parent OS. I haven't tested this, but if it's true,
> the use of Casper for cloning would always be easiest way to go.
>
> *TimDaniels*
>
>

Timothy Daniels[_3_]

August 7th 08, 01:09 AM

And... since one does not have to edit the registry when
using Casper, using Casper is the easiest way to go.

But what has not been addressed in this thread is why
random files seem to have shortcuts in the file table that
point to the "parent's" files rather than the clone's files if the
clone is started up on its first run with the "parent" OS still
visible to it. Is that explained by the MountedDevices
database and disk/partition signatures?

*TimDaniels*

"John John (MVP)" wrote:
> There is no rocket science involved in this, drive letters are
> assigned during the boot process, signatures and the Mount
> Manager's database are at the heart of persistent drive lettering.
> There is nothing miraculous about Casper, it simply modifies
> the clone's MountedDevices database and switches the drive
> letter of the clone's drive/partition so that it boots to the same
> letter as the original installation, in essence it preemptively does
> the procedure in the article that I mentioned earlier, anyone can
> do that manually while using any other cloning utility.
>
> There are only three ways around the persistent drive lettering:
>
> 1- Modify the drive letters to suit in the MountedDevices key.
>
> 2- Remove all the entries in the Mount Manager's database.
> When Windows is booted the IOAssignDriveLetters function
> will rely on a set of predetermined rules to assign drive letters.
> The installation may or may not adopt the correct drive letter,
> it depends on which letter you want the installation to adopt
> and on how the drives are enumerated by NTDETECT.COM.
>
> 3- Whack the disk signatures, this will automatically invalidate
> the Mount Manager database and the drives will be assigned
> letters based on the predetermined set of rules. Removing or
> disconnecting the parent has the same effect as whacking the
> signature, it invalidates the Mount Manager's database entries
> that deals with the now non existent signatures, those drive
> letters are now available for reassignment.
>
> John
>
> Timothy Daniels wrote:
>
>> "John John (MVP)" wrote:
>>
>>>if you boot the clone and it boots to D:
>>
>>
>> By this I assume you mean that it calls its own
>> partition "D:".
>>
>>
>>>then you will have to do the procedure to return the drive
>>>assignment to C:, you can simply do it before you boot the
>>>clone and be done with it. It is a heck of a lot easier to edit
>>>the registry than to use third party tools and to do the bunch
>>>of steps that you suggest, but to each his own.
>>>
>>>John
>>
>>
>> I prefer to stay out of the registry, and a "bunch of steps"
>> is a result of my having listed the steps in detail. I'm sure
>> that editing the registry, when explained in detail, also
>> involves a "bunch of steps".
>>
>> Since we both agree that hiding the "parent" OS from
>> view of the clone only needs a 3rd-party utility if the
>> "parent" and clone partitions are on the same disk, i.e.
>> when the "parent" OS can't be hidden by simply
>> disconnecting its hard disk, it's interesting to note that
>> the authors of the cloning utility "Casper", beginning with
>> version 4.0, say that Casper can make a clone on the
>> same disk as the "parent" and not have any difficulties
>> when it's started up for the first time - even when it can
>> "see" its parent OS. I haven't tested this, but if it's true,
>> the use of Casper for cloning would always be easiest
>> way to go.
>>
>> *TimDaniels*
>>

John John (MVP)

August 7th 08, 01:42 AM

I prefer other cloning utilities, I don't use Casper and I have no
problems editing the clone's registry, it's a matter of preference as to
what others chose to do.

I don't know what you mean by random files having shortcut to the file
table. What do you mean by that? What do you call the file table? I
think what you are seeing is simply the result of the boot volume not
maintaining the proper drive letter and that all the pointers in your
shortcuts and registry are simply pointing to the original drive letter.
For example: You clone drive C: to another partition and you do not
take steps to ensure that the clone adopt drive letter C: when it boots,
and you keep the parent online and it keeps its original C: drive
letter. All your shortcuts and all the registry pointers point to files
on C: so when you are using the clone which was assigned a letter other
than C:, all it's file references are pointing to files on the C: drive,
the original installation. Had the clone been properly assigned drive
C: then all the pointers would point to the files on the clone's partition.

John

Timothy Daniels wrote:
> And... since one does not have to edit the registry when
> using Casper, using Casper is the easiest way to go.
>
> But what has not been addressed in this thread is why
> random files seem to have shortcuts in the file table that
> point to the "parent's" files rather than the clone's files if the
> clone is started up on its first run with the "parent" OS still
> visible to it. Is that explained by the MountedDevices
> database and disk/partition signatures?
>
> *TimDaniels*
>
> "John John (MVP)" wrote:
>
>>There is no rocket science involved in this, drive letters are
>>assigned during the boot process, signatures and the Mount
>>Manager's database are at the heart of persistent drive lettering.
>>There is nothing miraculous about Casper, it simply modifies
>>the clone's MountedDevices database and switches the drive
>>letter of the clone's drive/partition so that it boots to the same
>>letter as the original installation, in essence it preemptively does
>>the procedure in the article that I mentioned earlier, anyone can
>>do that manually while using any other cloning utility.
>>
>>There are only three ways around the persistent drive lettering:
>>
>>1- Modify the drive letters to suit in the MountedDevices key.
>>
>>2- Remove all the entries in the Mount Manager's database.
>>When Windows is booted the IOAssignDriveLetters function
>>will rely on a set of predetermined rules to assign drive letters.
>>The installation may or may not adopt the correct drive letter,
>>it depends on which letter you want the installation to adopt
>>and on how the drives are enumerated by NTDETECT.COM.
>>
>>3- Whack the disk signatures, this will automatically invalidate
>>the Mount Manager database and the drives will be assigned
>>letters based on the predetermined set of rules. Removing or
>>disconnecting the parent has the same effect as whacking the
>>signature, it invalidates the Mount Manager's database entries
>>that deals with the now non existent signatures, those drive
>>letters are now available for reassignment.
>>
>>John
>>
>>Timothy Daniels wrote:
>>
>>
>>> "John John (MVP)" wrote:
>>>
>>>
>>>>if you boot the clone and it boots to D:
>>>
>>>
>>> By this I assume you mean that it calls its own
>>> partition "D:".
>>>
>>>
>>>
>>>>then you will have to do the procedure to return the drive
>>>>assignment to C:, you can simply do it before you boot the
>>>>clone and be done with it. It is a heck of a lot easier to edit
>>>>the registry than to use third party tools and to do the bunch
>>>>of steps that you suggest, but to each his own.
>>>>
>>>>John
>>>
>>>
>>> I prefer to stay out of the registry, and a "bunch of steps"
>>>is a result of my having listed the steps in detail. I'm sure
>>>that editing the registry, when explained in detail, also
>>>involves a "bunch of steps".
>>>
>>> Since we both agree that hiding the "parent" OS from
>>>view of the clone only needs a 3rd-party utility if the
>>>"parent" and clone partitions are on the same disk, i.e.
>>>when the "parent" OS can't be hidden by simply
>>>disconnecting its hard disk, it's interesting to note that
>>>the authors of the cloning utility "Casper", beginning with
>>>version 4.0, say that Casper can make a clone on the
>>>same disk as the "parent" and not have any difficulties
>>>when it's started up for the first time - even when it can
>>>"see" its parent OS. I haven't tested this, but if it's true,
>>>the use of Casper for cloning would always be easiest
>>>way to go.
>>>
>>>*TimDaniels*
>>>
>
>

Timothy Daniels[_3_]

August 8th 08, 01:26 AM

I and others posting in the NGs - most commonly in
"comp.sys.ibm.pc.hardware.storage" (a NG about hard drives) -
have seen just as I've described: Random and sparse shortcuts
that lead to files in the "parent's" file structure instead of to the
identically named files in the clone's file structure. To be painfully
explicit, suppose I had a file with the pathname in my "parent"
OS's partition:
C:\Documents and Settings\Tim\My Documents\Fax\Coverpage.

This same file with the same path appears in the clone (which
had been started up for the first time while its "parent" OS was
visible to the clone). But instead of actually pointing to the clone's
copy of the file, it actually points back to the "parent's" file.
With the clone running, one edits the file from time to time over
a period of a few weeks, and all seems fine - the edits appear
whenever the file is inspected. Convinced that the clone is
fine on the new hard drive, one deletes the "parent's" file, or the
"parent's" entire partition, on the old hard drive - and the clone's
file disappears! But this happens only for a *few* files, and
looking for which files have disappeared is like looking for
toothpicks in a haystack. That is what I refer to as "random
and sparse shortcuts being made that point to the 'parent's' files".
It's usually and easily overlooked since the occurrences are
random and sparse, not affecting all files in the clone - or even
affecting 10% of the files - and since they are random, they are
not reproduceable. But I have seen it happen. And no one has
ever shown what the mechanism is.

*TimDaniels*

"John John (MVP)" wrote:
>I prefer other cloning utilities, I don't use Casper and I have no problems
>editing the clone's registry, it's a matter of preference
> as to what others chose to do.
>
> I don't know what you mean by random files having shortcut to
> the file table. What do you mean by that? What do you call the
> file table? I think what you are seeing is simply the result of the
> boot volume not maintaining the proper drive letter and that all
> the pointers in your shortcuts and registry are simply pointing to
> the original drive letter. For example: You clone drive C: to
> another partition and you do not take steps to ensure that the
> clone adopt drive letter C: when it boots, and you keep the
> parent online and it keeps its original C: drive letter. All your
> shortcuts and all the registry pointers point to files on C: so when
> you are using the clone which was assigned a letter other than C:,
> all it's file references are pointing to files on the C: drive, the
> original installation. Had the clone been properly assigned drive C:
> then all the pointers would point to the files on the clone's partition.
>
> John
>
> Timothy Daniels wrote:
>> And... since one does not have to edit the registry when
>> using Casper, using Casper is the easiest way to go.
>>
>> But what has not been addressed in this thread is why
>> random files seem to have shortcuts in the file table that
>> point to the "parent's" files rather than the clone's files if the
>> clone is started up on its first run with the "parent" OS still
>> visible to it. Is that explained by the MountedDevices
>> database and disk/partition signatures?
>>
>> *TimDaniels*
>>
>> "John John (MVP)" wrote:
>>
>>>There is no rocket science involved in this, drive letters are
>>>assigned during the boot process, signatures and the Mount
>>>Manager's database are at the heart of persistent drive lettering.
>>>There is nothing miraculous about Casper, it simply modifies
>>>the clone's MountedDevices database and switches the drive
>>>letter of the clone's drive/partition so that it boots to the same
>>>letter as the original installation, in essence it preemptively does
>>>the procedure in the article that I mentioned earlier, anyone can
>>>do that manually while using any other cloning utility.
>>>
>>>There are only three ways around the persistent drive lettering:
>>>
>>>1- Modify the drive letters to suit in the MountedDevices key.
>>>
>>>2- Remove all the entries in the Mount Manager's database.
>>>When Windows is booted the IOAssignDriveLetters function
>>>will rely on a set of predetermined rules to assign drive letters.
>>>The installation may or may not adopt the correct drive letter,
>>>it depends on which letter you want the installation to adopt
>>>and on how the drives are enumerated by NTDETECT.COM.
>>>
>>>3- Whack the disk signatures, this will automatically invalidate
>>>the Mount Manager database and the drives will be assigned
>>>letters based on the predetermined set of rules. Removing or
>>>disconnecting the parent has the same effect as whacking the
>>>signature, it invalidates the Mount Manager's database entries
>>>that deals with the now non existent signatures, those drive
>>>letters are now available for reassignment.
>>>
>>>John
>>>
>>>Timothy Daniels wrote:
>>>
>>>
>>>> "John John (MVP)" wrote:
>>>>
>>>>
>>>>>if you boot the clone and it boots to D:
>>>>
>>>>
>>>> By this I assume you mean that it calls its own
>>>> partition "D:".
>>>>
>>>>
>>>>
>>>>>then you will have to do the procedure to return the drive
>>>>>assignment to C:, you can simply do it before you boot the
>>>>>clone and be done with it. It is a heck of a lot easier to edit
>>>>>the registry than to use third party tools and to do the bunch
>>>>>of steps that you suggest, but to each his own.
>>>>>
>>>>>John
>>>>
>>>>
>>>> I prefer to stay out of the registry, and a "bunch of steps"
>>>>is a result of my having listed the steps in detail. I'm sure
>>>>that editing the registry, when explained in detail, also
>>>>involves a "bunch of steps".
>>>>
>>>> Since we both agree that hiding the "parent" OS from
>>>>view of the clone only needs a 3rd-party utility if the
>>>>"parent" and clone partitions are on the same disk, i.e.
>>>>when the "parent" OS can't be hidden by simply
>>>>disconnecting its hard disk, it's interesting to note that
>>>>the authors of the cloning utility "Casper", beginning with
>>>>version 4.0, say that Casper can make a clone on the
>>>>same disk as the "parent" and not have any difficulties
>>>>when it's started up for the first time - even when it can
>>>>"see" its parent OS. I haven't tested this, but if it's true,
>>>>the use of Casper for cloning would always be easiest
>>>>way to go.
>>>>
>>>>*TimDaniels*
>>>>
>>

John John (MVP)

August 8th 08, 01:34 AM

I have never seen that. If the shortcut is set to a file on drive C:
then it will find the file on that drive, not on a drive by another
letter. I can only surmise that users aren't aware of which drive
letter their clone is actually using, using the SET command will reveal
which drive they are actually using.

John

Timothy Daniels wrote:

> I and others posting in the NGs - most commonly in
> "comp.sys.ibm.pc.hardware.storage" (a NG about hard drives) -
> have seen just as I've described: Random and sparse shortcuts
> that lead to files in the "parent's" file structure instead of to the
> identically named files in the clone's file structure. To be painfully
> explicit, suppose I had a file with the pathname in my "parent"
> OS's partition:
> C:\Documents and Settings\Tim\My Documents\Fax\Coverpage.
>
> This same file with the same path appears in the clone (which
> had been started up for the first time while its "parent" OS was
> visible to the clone). But instead of actually pointing to the clone's
> copy of the file, it actually points back to the "parent's" file.
> With the clone running, one edits the file from time to time over
> a period of a few weeks, and all seems fine - the edits appear
> whenever the file is inspected. Convinced that the clone is
> fine on the new hard drive, one deletes the "parent's" file, or the
> "parent's" entire partition, on the old hard drive - and the clone's
> file disappears! But this happens only for a *few* files, and
> looking for which files have disappeared is like looking for
> toothpicks in a haystack. That is what I refer to as "random
> and sparse shortcuts being made that point to the 'parent's' files".
> It's usually and easily overlooked since the occurrences are
> random and sparse, not affecting all files in the clone - or even
> affecting 10% of the files - and since they are random, they are
> not reproduceable. But I have seen it happen. And no one has
> ever shown what the mechanism is.
>
> *TimDaniels*
>
> "John John (MVP)" wrote:
>
>>I prefer other cloning utilities, I don't use Casper and I have no problems
>>editing the clone's registry, it's a matter of preference
>>as to what others chose to do.
>>
>>I don't know what you mean by random files having shortcut to
>>the file table. What do you mean by that? What do you call the
>>file table? I think what you are seeing is simply the result of the
>>boot volume not maintaining the proper drive letter and that all
>>the pointers in your shortcuts and registry are simply pointing to
>>the original drive letter. For example: You clone drive C: to
>>another partition and you do not take steps to ensure that the
>>clone adopt drive letter C: when it boots, and you keep the
>>parent online and it keeps its original C: drive letter. All your
>>shortcuts and all the registry pointers point to files on C: so when
>>you are using the clone which was assigned a letter other than C:,
>>all it's file references are pointing to files on the C: drive, the
>>original installation. Had the clone been properly assigned drive C:
>>then all the pointers would point to the files on the clone's partition.
>>
>>John
>>
>>Timothy Daniels wrote:
>>
>>> And... since one does not have to edit the registry when
>>>using Casper, using Casper is the easiest way to go.
>>>
>>> But what has not been addressed in this thread is why
>>>random files seem to have shortcuts in the file table that
>>>point to the "parent's" files rather than the clone's files if the
>>>clone is started up on its first run with the "parent" OS still
>>>visible to it. Is that explained by the MountedDevices
>>>database and disk/partition signatures?
>>>
>>>*TimDaniels*
>>>
>>>"John John (MVP)" wrote:
>>>
>>>
>>>>There is no rocket science involved in this, drive letters are
>>>>assigned during the boot process, signatures and the Mount
>>>>Manager's database are at the heart of persistent drive lettering.
>>>>There is nothing miraculous about Casper, it simply modifies
>>>>the clone's MountedDevices database and switches the drive
>>>>letter of the clone's drive/partition so that it boots to the same
>>>>letter as the original installation, in essence it preemptively does
>>>>the procedure in the article that I mentioned earlier, anyone can
>>>>do that manually while using any other cloning utility.
>>>>
>>>>There are only three ways around the persistent drive lettering:
>>>>
>>>>1- Modify the drive letters to suit in the MountedDevices key.
>>>>
>>>>2- Remove all the entries in the Mount Manager's database.
>>>>When Windows is booted the IOAssignDriveLetters function
>>>>will rely on a set of predetermined rules to assign drive letters.
>>>>The installation may or may not adopt the correct drive letter,
>>>>it depends on which letter you want the installation to adopt
>>>>and on how the drives are enumerated by NTDETECT.COM.
>>>>
>>>>3- Whack the disk signatures, this will automatically invalidate
>>>>the Mount Manager database and the drives will be assigned
>>>>letters based on the predetermined set of rules. Removing or
>>>>disconnecting the parent has the same effect as whacking the
>>>>signature, it invalidates the Mount Manager's database entries
>>>>that deals with the now non existent signatures, those drive
>>>>letters are now available for reassignment.
>>>>
>>>>John
>>>>
>>>>Timothy Daniels wrote:
>>>>
>>>>
>>>>
>>>>>"John John (MVP)" wrote:
>>>>>
>>>>>
>>>>>
>>>>>>if you boot the clone and it boots to D:
>>>>>
>>>>>
>>>>> By this I assume you mean that it calls its own
>>>>> partition "D:".
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>then you will have to do the procedure to return the drive
>>>>>>assignment to C:, you can simply do it before you boot the
>>>>>>clone and be done with it. It is a heck of a lot easier to edit
>>>>>>the registry than to use third party tools and to do the bunch
>>>>>>of steps that you suggest, but to each his own.
>>>>>>
>>>>>>John
>>>>>
>>>>>
>>>>> I prefer to stay out of the registry, and a "bunch of steps"
>>>>>is a result of my having listed the steps in detail. I'm sure
>>>>>that editing the registry, when explained in detail, also
>>>>>involves a "bunch of steps".
>>>>>
>>>>> Since we both agree that hiding the "parent" OS from
>>>>>view of the clone only needs a 3rd-party utility if the
>>>>>"parent" and clone partitions are on the same disk, i.e.
>>>>>when the "parent" OS can't be hidden by simply
>>>>>disconnecting its hard disk, it's interesting to note that
>>>>>the authors of the cloning utility "Casper", beginning with
>>>>>version 4.0, say that Casper can make a clone on the
>>>>>same disk as the "parent" and not have any difficulties
>>>>>when it's started up for the first time - even when it can
>>>>>"see" its parent OS. I haven't tested this, but if it's true,
>>>>>the use of Casper for cloning would always be easiest
>>>>>way to go.
>>>>>
>>>>>*TimDaniels*
>>>>>
>>>
>

Timothy Daniels[_3_]

August 8th 08, 06:52 AM

You seem to assume that my use of "shorcut" is a reference to
a link that I or someone else created. I'm saying that it is a
spontaneous and random and rare occurrence that happens for
a few files if the clone sees its "parent" OS when the clone starts
up for the very first time, and not at all for the vast majority of the
files in the clone's partition. This inconsistency is why it's so
insidious - most people never miss the file that eventually "disappears"
when they get rid of the "parent" OS. Sometimes the file is critical,
perhaps a configuration file, and its absence becomes known
immediately. But many times the user never misses it. Of course,
if it affected *all* the files on the clone's partition, you could attribute
it to a drive name gone awry. But it only affects a few files, perhaps
just one, perhaps sometimes none at all. *That* is why I don't think
the MountedDevices key is the explanation for this particular problem.
It can explain why *all* file references might be to files in the "parent"
OS, but not why just a few files might actually be the "parent's" files.

*TimDaniels*

"John John (MVP)" wrote:
>I have never seen that. If the shortcut is set to a file on drive C: then it
>will find the file on that drive, not on a drive by another letter. I can only
>surmise that users aren't aware of which drive letter their clone is actually
>using, using the SET command will
> reveal which drive they are actually using.
>
> John
>
> Timothy Daniels wrote:
>
>> I and others posting in the NGs - most commonly in
>> "comp.sys.ibm.pc.hardware.storage" (a NG about hard drives) -
>> have seen just as I've described: Random and sparse shortcuts
>> that lead to files in the "parent's" file structure instead of to the
>> identically named files in the clone's file structure. To be painfully
>> explicit, suppose I had a file with the pathname in my "parent"
>> OS's partition:
>> C:\Documents and Settings\Tim\My Documents\Fax\Coverpage.
>>
>> This same file with the same path appears in the clone (which
>> had been started up for the first time while its "parent" OS was
>> visible to the clone). But instead of actually pointing to the clone's
>> copy of the file, it actually points back to the "parent's" file.
>> With the clone running, one edits the file from time to time over
>> a period of a few weeks, and all seems fine - the edits appear
>> whenever the file is inspected. Convinced that the clone is
>> fine on the new hard drive, one deletes the "parent's" file, or the
>> "parent's" entire partition, on the old hard drive - and the clone's
>> file disappears! But this happens only for a *few* files, and
>> looking for which files have disappeared is like looking for
>> toothpicks in a haystack. That is what I refer to as "random
>> and sparse shortcuts being made that point to the 'parent's' files".
>> It's usually and easily overlooked since the occurrences are
>> random and sparse, not affecting all files in the clone - or even
>> affecting 10% of the files - and since they are random, they are
>> not reproduceable. But I have seen it happen. And no one has
>> ever shown what the mechanism is.
>>
>> *TimDaniels*
>>
>> "John John (MVP)" wrote:
>>
>>>I prefer other cloning utilities, I don't use Casper and I have no problems
>>>editing the clone's registry, it's a matter of preference
>>>as to what others chose to do.
>>>
>>>I don't know what you mean by random files having shortcut to
>>>the file table. What do you mean by that? What do you call the
>>>file table? I think what you are seeing is simply the result of the
>>>boot volume not maintaining the proper drive letter and that all
>>>the pointers in your shortcuts and registry are simply pointing to
>>>the original drive letter. For example: You clone drive C: to
>>>another partition and you do not take steps to ensure that the
>>>clone adopt drive letter C: when it boots, and you keep the
>>>parent online and it keeps its original C: drive letter. All your
>>>shortcuts and all the registry pointers point to files on C: so when
>>>you are using the clone which was assigned a letter other than C:,
>>>all it's file references are pointing to files on the C: drive, the
>>>original installation. Had the clone been properly assigned drive C:
>>>then all the pointers would point to the files on the clone's partition.
>>>
>>>John
>>>
>>>Timothy Daniels wrote:
>>>
>>>> And... since one does not have to edit the registry when
>>>>using Casper, using Casper is the easiest way to go.
>>>>
>>>> But what has not been addressed in this thread is why
>>>>random files seem to have shortcuts in the file table that
>>>>point to the "parent's" files rather than the clone's files if the
>>>>clone is started up on its first run with the "parent" OS still
>>>>visible to it. Is that explained by the MountedDevices
>>>>database and disk/partition signatures?
>>>>
>>>>*TimDaniels*
>>>>
>>>>"John John (MVP)" wrote:
>>>>
>>>>
>>>>>There is no rocket science involved in this, drive letters are
>>>>>assigned during the boot process, signatures and the Mount
>>>>>Manager's database are at the heart of persistent drive lettering.
>>>>>There is nothing miraculous about Casper, it simply modifies
>>>>>the clone's MountedDevices database and switches the drive
>>>>>letter of the clone's drive/partition so that it boots to the same
>>>>>letter as the original installation, in essence it preemptively does
>>>>>the procedure in the article that I mentioned earlier, anyone can
>>>>>do that manually while using any other cloning utility.
>>>>>
>>>>>There are only three ways around the persistent drive lettering:
>>>>>
>>>>>1- Modify the drive letters to suit in the MountedDevices key.
>>>>>
>>>>>2- Remove all the entries in the Mount Manager's database.
>>>>>When Windows is booted the IOAssignDriveLetters function
>>>>>will rely on a set of predetermined rules to assign drive letters.
>>>>>The installation may or may not adopt the correct drive letter,
>>>>>it depends on which letter you want the installation to adopt
>>>>>and on how the drives are enumerated by NTDETECT.COM.
>>>>>
>>>>>3- Whack the disk signatures, this will automatically invalidate
>>>>>the Mount Manager database and the drives will be assigned
>>>>>letters based on the predetermined set of rules. Removing or
>>>>>disconnecting the parent has the same effect as whacking the
>>>>>signature, it invalidates the Mount Manager's database entries
>>>>>that deals with the now non existent signatures, those drive
>>>>>letters are now available for reassignment.
>>>>>
>>>>>John
>>>>>
>>>>>Timothy Daniels wrote:
>>>>>
>>>>>
>>>>>
>>>>>>"John John (MVP)" wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>if you boot the clone and it boots to D:
>>>>>>
>>>>>>
>>>>>> By this I assume you mean that it calls its own
>>>>>> partition "D:".
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>then you will have to do the procedure to return the drive
>>>>>>>assignment to C:, you can simply do it before you boot the
>>>>>>>clone and be done with it. It is a heck of a lot easier to edit
>>>>>>>the registry than to use third party tools and to do the bunch
>>>>>>>of steps that you suggest, but to each his own.
>>>>>>>
>>>>>>>John
>>>>>>
>>>>>>
>>>>>> I prefer to stay out of the registry, and a "bunch of steps"
>>>>>>is a result of my having listed the steps in detail. I'm sure
>>>>>>that editing the registry, when explained in detail, also
>>>>>>involves a "bunch of steps".
>>>>>>
>>>>>> Since we both agree that hiding the "parent" OS from
>>>>>>view of the clone only needs a 3rd-party utility if the
>>>>>>"parent" and clone partitions are on the same disk, i.e.
>>>>>>when the "parent" OS can't be hidden by simply
>>>>>>disconnecting its hard disk, it's interesting to note that
>>>>>>the authors of the cloning utility "Casper", beginning with
>>>>>>version 4.0, say that Casper can make a clone on the
>>>>>>same disk as the "parent" and not have any difficulties
>>>>>>when it's started up for the first time - even when it can
>>>>>>"see" its parent OS. I haven't tested this, but if it's true,
>>>>>>the use of Casper for cloning would always be easiest
>>>>>>way to go.
>>>>>>
>>>>>>*TimDaniels*
>>>>>>
>>>>
>>