Cloning problems

*TimDaniels*
No, after cloning, both drives are "DRIVE C".
Take a peek with XP at the second drive and it is no longer drive c.
So, after cloning, remove it and use it only a primary drive.
Never have both drives in the machine, except when cloning.


Both drives ar C: *only* if you boot from the clone...
if you reboot and leave it attached it will be assigned the next drive
letter.

Once you boot from it, it becomes C:


Of course if you later attach it as a second drive
the operating system will assign the next drive up.

On Sat, 19 Mar 2011 13:17:40 -0700, "Timothy Daniels"
wrote:

That's too restrictive. As long as the clone is alone (not able to
"see" its parent OS) when it boots up for *the first time*, both the
parent and the clone can be allowed to "see" each other. The OS
which is not running will just be seen as data.

When I first started cloning like this a year or so back I did test
the clone by disconnecting the 'old' C: and connecting the cloned
drive in its place. It was seen as 'C:". Thereafter, when I wanted to
clone, I would just connect power to the cloned drive and boot into
WinXP with both drives connected. The cloned drive appeared as D: and
didn't seem to harm anything. Then I would re-clone, from within
Windows. This necessitated a reboot, and on the way up, the data was
written on the clone.
20 minutes after I posed this question if FINALLY occurred to me that
I already had the answer in Maxtor's MaxBlast utility. It allows you
to make a bootable CD and perform cloning from outside Windows. That's
what I did.
The mystery remains: why did not having both drive copies, C: and D:
active in Windows never bother for a year, and then it did.
The secondary mystery, why I took such a long route to the simple
answer, can be answered by my advanced age, and my history of making
hard work of problems all my life.

"John B. Smith" shared:
"Timothy Daniels" wrote:

That's too restrictive. As long as the clone is alone (not able to
"see" its parent OS) when it boots up for *the first time*, both the
parent and the clone can be allowed to "see" each other. The OS
which is not running will just be seen as data.

When I first started cloning like this a year or so back I did test
the clone by disconnecting the 'old' C: and connecting the cloned
drive in its place. It was seen as 'C:". Thereafter, when I wanted to
clone, I would just connect power to the cloned drive and boot into
WinXP with both drives connected. The cloned drive appeared as D:
and didn't seem to harm anything. Then I would re-clone, from within
Windows. This necessitated a reboot, and on the way up, the data
was written on the clone.

Yes, the clone drive appeared as D: because it did not contain the
running OS - which was still the "parent" OS. This suggests that you
never booted the clone OS but merely made periodic clones for
archival purposes.

By connecting power to the "cloned" drive and booting into XP with
both drives connected doesn't say whether you changed the setting for
the hard drive boot priority. In sounds like you did not and that the hard
drive with the "parent" OS continued as the boot drive even when the
drive that was to receive the clone had power. That was why the "cloned"
drive was assigned the drive letter "D".

And since you didn't mention resetting the hard drive boot priority,
you either never ran the clone OS, or you first cabled up the clone drive
as the "parent" drive before booting up, leaving the "parent" drive
unconnected, or you disconnected the "parent" drive and connected the
cloned drive, which allowed the clone to boot up in isolation. These
scenarios do not involve letting the booted clone OS see its "parent" OS
when the clone is booted for the first time in its new "life".


20 minutes after I posed this question i[t] FINALLY occurred to me
that I already had the answer in Maxtor's MaxBlast utility. It allows
you to make a bootable CD and perform cloning from outside
Windows. That's what I did.
The mystery remains: why did not having both drive copies, C: and D:
active in Windows never bother for a year, and then it did. [....]


You don't describe the "bother" that happened, but I suspect
that a clone was booted up for its first run while the drive containing
the "parent" OS was still powered and connected. That can lead to
problems that are sometimes subtle and undetected. The only time
that I've seen such a problem is when I noticed that the clone that
had been allowed to boot for its first time while the "parent" OS was
visible to it didn't have a file but instead there was a shortcut pointing
to the old file:. While the clone drive was connected, I could edit the
file on the clone drive using the running "parent" OS. But when I dis-
connected the "parent" drive, the file on the clone drive didn't show the
edit - only the file on the "parent" drive had been edited. IOW, the
file hadn't really been copied to the clone - just a shortcut had been
made which pointed back to the file on the "parent" drive. As long
as both drives were connected, this error couldn't be detected.
Only when the clone ran alone did I notice that the file was inaccessible.
Such hard-to-detect errors are why this problem is not widely recognized
(except for people who read the comp.sys.ibm.pc.hardware.storage NG).
Why this happens I don't know, but Microsoft could easily correct it *if*
it wanted to. I suspect that it is one way that Microsoft uses to hinder
pirating of its OSes.

*TimDaniels*