Programs not working right after cloning

"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*

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*
>
>

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*
>>

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*
>>>
>
>

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*
>>>>
>>

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*
>>>>>
>>>
>

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*
>>>>>>
>>>>
>>