Is this a known problem, and is there a workaround ?
--
You received this message because you are subscribed to the Google Groups "The Xxclone Forum" group.
To post to this group, send email to xxc...@googlegroups.com.
To unsubscribe from this group, send email to xxclone+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/xxclone?hl=en.
The Recovery partition screws up the Paragon HDM 2009 Suite pretty
good. Anything that needs a reboot to continue fails as this reboot is
looking for something on the first partition (is my best guess)?
Paragon Support "is busy improving their 64 bit support in the next
version"!
And the 64 bit heavy Junction Point system screws up SyncBackSE really
good. According to 2BrightSparks Support "their software is 32 bit and
'Silently Diverts' the old 32 bit paths to the newer 64 bit paths".
Interpretation - it simply screws up really big time right where it
counts the most. However, enabling Always use the Volume Shadow Copy
(in the Profile's Advanced settings) will work around this problem for
now. And it does quite nicely, but at greatly increased time overhead.
Until the Windows7 boot manger is understood (bcdedit.exe), I'll be
keeping the Recover partition! Getting rid of the Data partiton is
easy, just Delete it in Disk Management (it's only an Extended
partition) and Resize C: to the rest of the disk. Nothing lost but D:.
The point of it was supposed to be to be able to Restore Windows
without touching your data. I say Forget Restoration and make a Clone
of everything!
So... I'd made a Clone before then on a hard drive identical to the
system's 2.5" 320 GB 5400 RPM SATA unit on a 2.5" 320 GB 7200 RPM SATA
disk, in a USB enclosure. (This laptop doesn't have an eSATA port.)
Looking in the registry, Windows7 recognizes and Mounts this just like
an internal drive. The recovery & OS partitions were copied to the new
drive using the Paragon HDM 2009 Suite because I already owned this.
It will do this job as no partitions existed there previously. Trying
to copy an entire disk required a reboot first, failed, and screwed up
the MBR leaving behind the options to boot from "A" (on a laptop!), C:
Win\Viata (?), or Linux (which must have been what it was looking for,
I don't know). It will however Rewrite the MBR and correct this
(Phew)! Manually copying the partitions individually worked OK though,
although slow as hell while Windows is running.
This Copy creation then turned out to be manually convertible to a
Clone by the identical technique I use in XP. Swapping the Drive
Letter and Volume Label Assignments between the Source and Destination
in the registry of the Destination.
HKLM\System\MountedDevices\ is Exported. This .reg file is edited down
to the 4 lines of interest. The hex data (containing the VoloumeID
\Disk Signature) swapped for the 2 pairs. And the Load point changed
from "System" to a "False Key" name. This file then saved for future
cloning operations. The Destination System file (Hive) is then loaded
into the running registry (under HKLM) as the False Key. And the pre-
prepared .reg file Imported (or Merged). Then the Hive Unloaded,
writing it back to where it came from, now altered to reflect the
physical disk swap there. None of this presents any danger to the
running registry. Should the system go down the false key data is
simply lost as it's not part of the actual registry.
After testing out Maintenance of same with SyncBackSE (since I also
own that), and originally totally destroying the destination
partition, I tried another 'free' Cloning tool CloneZilla. Now that's
OK. A Live CD running a Linux app that doesn't care about bit types or
file systems, it just copies what ever's there. And re-copied the OS
partition only. It's uses the Linux designations for drives and
partitions, and would be 'different' for most users, but works quite
nicely. Just be careful about Source & Destination designations. I'll
probably stick with that for Creation, and SyncBackSE for Maintenance,
since that handles almost any data copy scenario I ever encounter, and
uses the Volume Shadow Copy Service for Open files getting the
registry, etc.
Have fun: DES
Reminded by Paragon Support, after complaining about their software
not handling my non-standard disk. I could have just used the HDM 2009
Suite Recover Disk. (Which is right over there on the shelf!) It's
another Live CD that can do pretty much anything the GUI Suite can do,
just not in as detailed an interface. I'd simply forgotten about this
benefit of owning the Suite, or any of their packages, as it's
something hardly ever used (until you're desperate).
Also, Windows7 is much more compliant than XP about things like
duplicate Volume Labels. A natural occurrence of copying a source
partition to a destination partition with Windows running, or
restarting Windows before catching up on the details. The HDM Suite
will allow changing this before finishing with the update, if you
remember! XP really doesn't like duplicate volume labels and can get
very confused if the duplicate is accessed. Windows7 seems to actually
try and access both drives at the same time even with different drive
letters(?), but recovers as soon as the destination label is
corrected.
In fact Windows7 handles all this resource mounting\unmounting much
better. Network shares simply come & go as available (as they should)
without any of the XP's searching for currently unconnected shares and
then losing them if not found. Initially I was down on it As
Everything is Different. But trying to be fair I'm finding a lot of
improvements that can only get better with familiarity.
DES