Windows 7 & diskettes

5 views
Skip to first unread message

Vlodec

unread,
Dec 21, 2009, 4:39:25 AM12/21/09
to The Xxclone Forum
I've been using xxclone with XP now for some months with no problems.
Then I installed Windows 7 Ultimate, 64 bit, and an issue has arisen.
When it gets to about 10 minutes from completion it asks for a
diskette. Something to do with a "dual boot" feature. The trouble is I
don't use a diskette drive, and haven't for years so I can't provide a
diskette.

Is this a known problem, and is there a workaround ?

Dan Anderson

unread,
Dec 21, 2009, 6:49:16 PM12/21/09
to xxc...@googlegroups.com
Hi Vlodec,
The short answer appears to be that xxclone is not designed to operate in a Win7 environment (as far as I know it was never operational for Vista either).
 
Dan

--

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.



DES

unread,
Dec 24, 2009, 8:48:18 PM12/24/09
to The Xxclone Forum
I finally jumped into the Windows7 world last week with a new laptop
running 64 bit Windows7 Home Premium. This machine's disk comes with 3
default partitions; a small Hidden FTA32 labeled Recovery, the OS C:
NTFS Primary, and Data D: NTFS logical. They probably felt they were
doing someone a favor?

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

DES

unread,
Dec 25, 2009, 12:22:12 PM12/25/09
to The Xxclone Forum
Nothing like replying to my own post. But there was something else I
left out.

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


Reply all
Reply to author
Forward
0 new messages