re: Do XXCOPY and XXCLONE work under Windows 7?
316 views
Skip to first unread message
Dan Anderson
Oct 1, 2010, 8:29:27 PM10/1/10
to xxc...@yahoogroups.com, xxc...@googlegroups.com
Apologies Roy. I shouldn't have commented off
the cuff on xxcopy. I thought this was coming through on the xxclone
discussion forum and should have restricted my comments to
xxclone. When you said Win7 I had a brain-blip and was thinking Vista
for xxcopy (I'm still back with XP) as I recalled seeing some comments to
that effect in the past.
After googling a bit, my impression is that the
answer for xxcopy is no for Win7 and yes for Vista. The following is
a link to a newsletter on some considerations that are specific to xxcopy
and Vista: http://www.xxcopy.com/xxtb_042.htm .
But I'll defer to the xxcopy experts.
I've copied your question to the xxclone discussion
forum as well in case anyone disagrees with my understanding that xxclone is not
intended to work on Vista nor on Win7. Des has had some success on a
different approach to cloning Win7 so he might want to comment if you would be
interested in alternatives.
Dan
----- Original Message -----From: Roy LipscombSent: Friday, October 01, 2010 7:49 PMSubject: Re: [xxcopy] Re: Do XXCOPY and XXCLONE work under Windows 7?The Pixilab websites are inconclusive about the answer to the question,
"Do XXCOPY and XXCLONE work under Windows 7?"
* XXCOPY says "Supports all Windows versions (except Windows CE)"
http://www.xxcopy.com/xcpywhat.htm
There's no date on that statement, so one can't tell if it predates
Windows 7 and thus says nothing about Windows 7.
* XXCLONE says "Supports all 32-bit Windows (95, 98, ME, NT4, 2000, XP)"
http://www.xxclone.com/iwhatis.htm
Does Windows 7 come in a 32-bit variety? If so, does the above statement
exclude Windows 7, or is the above statement merely out of date?
An explicit reference to Windows 7 (and to Vista, for that matter) would be
helpful in both statements above.
Regards,
Roy
On Fri, 1 Oct 2010, Dan Anderson wrote:
> Roy, I think the answer is yes for xxcopy and no for xxclone. You can check out their websites for specifics.
>
>
> ----------------------------------------------------------
>
> ----- Original Message -----
> From: Roy Lipscomb
> To: xxc...@yahoogroups.com
> Sent: Friday, October 01, 2010 5:47 PM
> Subject: [xxcopy] Do XXCOPY and XXCLONE work under Windows 7?
>
>
>
> Do XXCOPY and XXCLONE work under Windows 7?
>
> Regards,
>
> Roy
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>__._,_.___MARKETPLACE
.
__,_._,___
DES
Oct 2, 2010, 12:24:38 PM10/2/10
to The Xxclone Forum
xxclone never made it to Vista, hence Windows 7 is out too. The main
reason I suspect is the different boot configuration.
In these OS's the boot is controlled by a new System\Hidden\ file,
"BCD" (no extension), the Boot Store or Boot Configuration Data. In
Windows 7, located in the System\Hidden\ directory C:\Boot\ (clever!).
Disks are identified in this file with a GUID (Global Unique
Identifier). The only way I've found to get one of these assigned to a
disk is actually let Windows do it. Via a Windows 7 Repair Disk, which
Windows 7 can write it's self, or a Windows 7 Installation Disk.
Apparently no one yet knows how Windows generates these GUID's? There
is some software, EasyBCD (ha!), that can display and manipulate the
BCD, also that of a Clone but be careful! Also Windows contains the
means on the command line but this is even more reminiscent of the
good old days (difficult). None of these utilities can actually
generate a GUID, only Windows.
Making a Windows 7 clone consists of getting the source complete
copied, MBR, registry, everything. A good freebie is CloneZilla, which
is open source and uses the Linux destinations for Drives and
Partitions, but gets the job done. And this duplicate the Volume ID if
I remember correctly? Important for various software keyed to same for
copy protection. If this disk is connected along side the source then
obviously it will wind up with it's own Drive Letter and Volume Label
assignments. Which appear in the source registry at HKLM\SYSTEM
\MountedDevices\, the DOS Devices and corresponding Volume lines. This
hasn't changed from XP (NT?), other then the drives are no longer
system assigned by VolumeID.
The xxclone "Make Bootable" operation must be preformed manually in
Windows 7. Export the MountedDevices Key from the source registry.
Edit it down to the 4 lines for source & destination Drive Letter and
Volume Label assignments. Swap the matching Binary Data between to two
pairs. And change the Load Point to a False Key. Save this .reg file.
Load the Destination System file into the running source registry as
the False Key assigned in the saved .reg file. Merge the save .reg
file preforming the swap. And Unload the modified False Key, which
writes it back to where it came from. Now every time the clone is
updated, this .reg file is available for correction of the updated
registry.
I use SyncBackSE for just about everything. It can copy Open\System
\Locked\Whatever files. Everything but the Windows 7 System Volume
Information, which will crash it thoroughly. Fortunately I don't use
System Restore, that's what the clone is for, and a much better
solution. So the \System Volume Information\ must be Excluded from the
update. Don't forget to Exclude the custom to the disk BCD file too (I
actually exclude the entire Boot directory). SyncBack has a fairly
comprehensive default System Filter that's worth examining for non
essential Windows copy items. And even SyncBack hasn't caught up with
all the Junction Points in Windows 7. Also in Windows 7 even the
Administrator doesn't have full permissions in a lot of directories.
Fortunately SyncBack has a couple of features that get around it all
for now. The Cloning Profile must be set up to Always use the Volume
Shadow Copy, to beat the fact that the running volume has many
junction points that make directories appear to have one name when
their actual name is something quite different on the non-running
destination. And there is a Backup Operator copy mode that just
completely ignores NTFS permissions. A much simpler solution than
trying to gain Ownership and grant Write Permissions all over the
disk. These copy modes more than quadruple the time to do a complete
disk Incremental Update compared to XP, but are the only solution
rather than a complete disk copy I currently know of.
Windows 7 is nearly twice as large as XP. And runs about twice the
number of Services and background applications. But it's performance
seems good. It's not perfect, Explorer has a habit of crashing on
large wireless to wireless transfers across my LAN. But it recovers
seamlessly. And it actually seems to work better than XP in may
respects. It's actually more User oriented. User Account Control just
incorporates XP's DropMyRights and\or Umbuntu's SUDO in a not too
intrusive format. I find myself liking the "things just work" of it
all!
DES
reason I suspect is the different boot configuration.
In these OS's the boot is controlled by a new System\Hidden\ file,
"BCD" (no extension), the Boot Store or Boot Configuration Data. In
Windows 7, located in the System\Hidden\ directory C:\Boot\ (clever!).
Disks are identified in this file with a GUID (Global Unique
Identifier). The only way I've found to get one of these assigned to a
disk is actually let Windows do it. Via a Windows 7 Repair Disk, which
Windows 7 can write it's self, or a Windows 7 Installation Disk.
Apparently no one yet knows how Windows generates these GUID's? There
is some software, EasyBCD (ha!), that can display and manipulate the
BCD, also that of a Clone but be careful! Also Windows contains the
means on the command line but this is even more reminiscent of the
good old days (difficult). None of these utilities can actually
generate a GUID, only Windows.
Making a Windows 7 clone consists of getting the source complete
copied, MBR, registry, everything. A good freebie is CloneZilla, which
is open source and uses the Linux destinations for Drives and
Partitions, but gets the job done. And this duplicate the Volume ID if
I remember correctly? Important for various software keyed to same for
copy protection. If this disk is connected along side the source then
obviously it will wind up with it's own Drive Letter and Volume Label
assignments. Which appear in the source registry at HKLM\SYSTEM
\MountedDevices\, the DOS Devices and corresponding Volume lines. This
hasn't changed from XP (NT?), other then the drives are no longer
system assigned by VolumeID.
The xxclone "Make Bootable" operation must be preformed manually in
Windows 7. Export the MountedDevices Key from the source registry.
Edit it down to the 4 lines for source & destination Drive Letter and
Volume Label assignments. Swap the matching Binary Data between to two
pairs. And change the Load Point to a False Key. Save this .reg file.
Load the Destination System file into the running source registry as
the False Key assigned in the saved .reg file. Merge the save .reg
file preforming the swap. And Unload the modified False Key, which
writes it back to where it came from. Now every time the clone is
updated, this .reg file is available for correction of the updated
registry.
I use SyncBackSE for just about everything. It can copy Open\System
\Locked\Whatever files. Everything but the Windows 7 System Volume
Information, which will crash it thoroughly. Fortunately I don't use
System Restore, that's what the clone is for, and a much better
solution. So the \System Volume Information\ must be Excluded from the
update. Don't forget to Exclude the custom to the disk BCD file too (I
actually exclude the entire Boot directory). SyncBack has a fairly
comprehensive default System Filter that's worth examining for non
essential Windows copy items. And even SyncBack hasn't caught up with
all the Junction Points in Windows 7. Also in Windows 7 even the
Administrator doesn't have full permissions in a lot of directories.
Fortunately SyncBack has a couple of features that get around it all
for now. The Cloning Profile must be set up to Always use the Volume
Shadow Copy, to beat the fact that the running volume has many
junction points that make directories appear to have one name when
their actual name is something quite different on the non-running
destination. And there is a Backup Operator copy mode that just
completely ignores NTFS permissions. A much simpler solution than
trying to gain Ownership and grant Write Permissions all over the
disk. These copy modes more than quadruple the time to do a complete
disk Incremental Update compared to XP, but are the only solution
rather than a complete disk copy I currently know of.
Windows 7 is nearly twice as large as XP. And runs about twice the
number of Services and background applications. But it's performance
seems good. It's not perfect, Explorer has a habit of crashing on
large wireless to wireless transfers across my LAN. But it recovers
seamlessly. And it actually seems to work better than XP in may
respects. It's actually more User oriented. User Account Control just
incorporates XP's DropMyRights and\or Umbuntu's SUDO in a not too
intrusive format. I find myself liking the "things just work" of it
all!
DES
Reply all
Reply to author
Forward
0 new messages