Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: How to compare clone of a partition with source partition
9 views
Skip to first unread message
Rod Speed
Jan 15, 2012, 12:18:17 AM1/15/12
to
AndyHancock wrote:
> I just cloned two partitions from a resident HDD to an auxiliary Momentus
> XL HDD in an enclosure that is connected to the computer via eSATA.
> Is there a way to compare each cloned partition with its original for integrity?
Not really with the system partition, because Norton's clones at the Win level
and the system partition will have changed since the clone was done, minimally.
If you had used something like True Image that can clone from a
Linux Live CD, it would have been possible to compare the partitions.
With non system partitions, like the recovery partitions,
you can certainly compare the partitions now.
> If this were just a file, I'd use a unix/cygwin utility like diff or cmp. However, it is a partition.
There are unix utes that can do binary comparisons of partitions. Arno listed one.
> I just cloned two partitions from a resident HDD to an auxiliary Momentus
> XL HDD in an enclosure that is connected to the computer via eSATA.
> Is there a way to compare each cloned partition with its original for integrity?
Not really with the system partition, because Norton's clones at the Win level
and the system partition will have changed since the clone was done, minimally.
If you had used something like True Image that can clone from a
Linux Live CD, it would have been possible to compare the partitions.
With non system partitions, like the recovery partitions,
you can certainly compare the partitions now.
> If this were just a file, I'd use a unix/cygwin utility like diff or cmp. However, it is a partition.
There are unix utes that can do binary comparisons of partitions. Arno listed one.
AndyHancock
Jan 15, 2012, 12:42:48 AM1/15/12
to
Arno
Jan 15, 2012, 8:39:23 AM1/15/12
to
In comp.sys.ibm.pc.hardware.storage AndyHancock <andymh...@gmail.com> wrote:
> I just cloned two partitions from a resident HDD to an auxiliary
> Momentus XL HDD in an enclosure that is connected to the computer via
> eSATA. Is there a way to compare each cloned partition with its
> original for integrity? If this were just a file, I'd use a unix/
> I just cloned two partitions from a resident HDD to an auxiliary
> Momentus XL HDD in an enclosure that is connected to the computer via
> eSATA. Is there a way to compare each cloned partition with its
> cygwin utility like diff or cmp. However, it is a partition.
If it is a bit-wise exact clone, cmp still works, but doing
md5sum or sha1sum on the whole partitions is faster.
On mimatch it tells you almost nothing though.
Or you can mount both, and do a file-tree comparison.
I do the following for that:
cd <dir1>; tar cf - .| (cd <dir2>; tar df -)
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: ar...@wagner.name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
AndyHancock
Jan 15, 2012, 2:43:36 PM1/15/12
to
On Jan 15, 8:39 am, Arno <m...@privacy.net> wrote:
in an abstract sense because I saw references to it as a unix user
(not admin). However, I also saw used the mount command in "file
system table" files in cygwin to make certain Windows letter drives
appear like POSIX paths.
I've only cloned 2 partitions so far, but will eventually clone 4.
Three of them are not letter-drives. Would this pose a problem for
any of these approaches?
> In comp.sys.ibm.pc.hardware.storage AndyHancock <andymhanc...@gmail.com> wrote:
>
> > I just cloned two partitions from a resident HDD to an auxiliary
> > Momentus XL HDD in an enclosure that is connected to the computer via
> > eSATA. Is there a way to compare each cloned partition with its
> > original for integrity? If this were just a file, I'd use a unix/
> > cygwin utility like diff or cmp. However, it is a partition.
>
> If it is a bit-wise exact clone, cmp still works, but doing
> md5sum or sha1sum on the whole partitions is faster.
> On mimatch it tells you almost nothing though.
>
> Or you can mount both, and do a file-tree comparison.
> I do the following for that:
>
> cd <dir1>; tar cf - .| (cd <dir2>; tar df -)
That sounds attractive. Just to be sure, I'm familiar with mounting
>
> > I just cloned two partitions from a resident HDD to an auxiliary
> > Momentus XL HDD in an enclosure that is connected to the computer via
> > eSATA. Is there a way to compare each cloned partition with its
> > original for integrity? If this were just a file, I'd use a unix/
> > cygwin utility like diff or cmp. However, it is a partition.
>
> If it is a bit-wise exact clone, cmp still works, but doing
> md5sum or sha1sum on the whole partitions is faster.
> On mimatch it tells you almost nothing though.
>
> Or you can mount both, and do a file-tree comparison.
> I do the following for that:
>
> cd <dir1>; tar cf - .| (cd <dir2>; tar df -)
in an abstract sense because I saw references to it as a unix user
(not admin). However, I also saw used the mount command in "file
system table" files in cygwin to make certain Windows letter drives
appear like POSIX paths.
I've only cloned 2 partitions so far, but will eventually clone 4.
Three of them are not letter-drives. Would this pose a problem for
any of these approaches?
Arno
Jan 15, 2012, 3:23:41 PM1/15/12
to
In comp.sys.ibm.pc.hardware.storage AndyHancock <andymh...@gmail.com> wrote:
> On Jan 15, 8:39?am, Arno <m...@privacy.net> wrote:
>> In comp.sys.ibm.pc.hardware.storage AndyHancock <andymhanc...@gmail.com> wrote:
>>
>> > I just cloned two partitions from a resident HDD to an auxiliary
>> > Momentus XL HDD in an enclosure that is connected to the computer via
>> > eSATA. ?Is there a way to compare each cloned partition with its
>> In comp.sys.ibm.pc.hardware.storage AndyHancock <andymhanc...@gmail.com> wrote:
>>
>> > I just cloned two partitions from a resident HDD to an auxiliary
>> > Momentus XL HDD in an enclosure that is connected to the computer via
>> > original for integrity? ?If this were just a file, I'd use a unix/
>> > cygwin utility like diff or cmp. ?However, it is a partition.
>>
>> If it is a bit-wise exact clone, cmp still works, but doing
>> md5sum or sha1sum on the whole partitions is faster.
>> On mimatch it tells you almost nothing though.
>>
>> Or you can mount both, and do a file-tree comparison.
>> I do the following for that:
>>
>> cd <dir1>; tar cf - .| (cd <dir2>; tar df -)
> That sounds attractive. Just to be sure, I'm familiar with mounting
> in an abstract sense because I saw references to it as a unix user
> (not admin). However, I also saw used the mount command in "file
> system table" files in cygwin to make certain Windows letter drives
> appear like POSIX paths.
> I've only cloned 2 partitions so far, but will eventually clone 4.
> Three of them are not letter-drives. Would this pose a problem for
> any of these approaches?
To be honest, I have no idea. My experience with Cygwin is very
>> If it is a bit-wise exact clone, cmp still works, but doing
>> md5sum or sha1sum on the whole partitions is faster.
>> On mimatch it tells you almost nothing though.
>>
>> Or you can mount both, and do a file-tree comparison.
>> I do the following for that:
>>
>> cd <dir1>; tar cf - .| (cd <dir2>; tar df -)
> That sounds attractive. Just to be sure, I'm familiar with mounting
> in an abstract sense because I saw references to it as a unix user
> (not admin). However, I also saw used the mount command in "file
> system table" files in cygwin to make certain Windows letter drives
> appear like POSIX paths.
> I've only cloned 2 partitions so far, but will eventually clone 4.
> Three of them are not letter-drives. Would this pose a problem for
> any of these approaches?
limited. Basically, for the comparison with "tar" to work, you need
to be able to cd into the first dir and specify the second one.
If they are already visible somewhere, that should be neough.
If not, "mounting" is the action of taking a device containing
a filesystem and attacking it so that the filesystem becomes
accessible somewhere.
Side note: Give the second "tar" a "v" first, e.g. "dvf" to see
the comparison is actually working, then interrypt and run
without the "v". Otherwise it is possible that nothing is actually
compared if there are problems with the path(s).
AndyHancock
Jan 15, 2012, 3:49:29 PM1/15/12
to
On Jan 15, 3:23 pm, Arno <m...@privacy.net> wrote:
>
> ...My experience with Cygwin is very
the amount of profanities I uttered at it over the years). If the
partitions can be made visible, and they are the file systems that are
meaningful and navigable by tar, this is a very appealing solution.
Thanks, I'll try to find out more about these non-letter-drive
partitions that Toshiba installs on their laptops. I know in concept
what they are related to (booting & recovery), but I'm still very
green on the plethora of files systems and such that can occupy the
partitions.
>
> ...My experience with Cygwin is very
> limited. Basically, for the comparison with "tar" to work, you need
> to be able to cd into the first dir and specify the second one.
> If they are already visible somewhere, that should be neough.
> If not, "mounting" is the action of taking a device containing
> a filesystem and attacking it so that the filesystem becomes
> accessible somewhere.
>
> Side note: Give the second "tar" a "v" first, e.g. "dvf" to see
> the comparison is actually working, then interrypt and run
> without the "v". Otherwise it is possible that nothing is actually
> compared if there are problems with the path(s).
I'm actually a big fan of tar (though you wouldn't have guessed from
> to be able to cd into the first dir and specify the second one.
> If they are already visible somewhere, that should be neough.
> If not, "mounting" is the action of taking a device containing
> a filesystem and attacking it so that the filesystem becomes
> accessible somewhere.
>
> Side note: Give the second "tar" a "v" first, e.g. "dvf" to see
> the comparison is actually working, then interrypt and run
> without the "v". Otherwise it is possible that nothing is actually
> compared if there are problems with the path(s).
the amount of profanities I uttered at it over the years). If the
partitions can be made visible, and they are the file systems that are
meaningful and navigable by tar, this is a very appealing solution.
Thanks, I'll try to find out more about these non-letter-drive
partitions that Toshiba installs on their laptops. I know in concept
what they are related to (booting & recovery), but I'm still very
green on the plethora of files systems and such that can occupy the
partitions.
Arno
Jan 15, 2012, 8:18:58 PM1/15/12
to
In comp.sys.ibm.pc.hardware.storage AndyHancock <andymh...@gmail.com> wrote:
> On Jan 15, 3:23 pm, Arno <m...@privacy.net> wrote:
>>
>> ...My experience with Cygwin is very
>> limited. Basically, for the comparison with "tar" to work, you need
>> to be able to cd into the first dir and specify the second one.
>> If they are already visible somewhere, that should be neough.
>> If not, "mounting" is the action of taking a device containing
>> a filesystem and attacking it so that the filesystem becomes
>> accessible somewhere.
>>
>> Side note: Give the second "tar" a "v" first, e.g. "dvf" to see
>> the comparison is actually working, then interrypt and run
>> without the "v". Otherwise it is possible that nothing is actually
>> compared if there are problems with the path(s).
> I'm actually a big fan of tar (though you wouldn't have guessed from
> the amount of profanities I uttered at it over the years).
Me too ;-)
>>
>> ...My experience with Cygwin is very
>> limited. Basically, for the comparison with "tar" to work, you need
>> to be able to cd into the first dir and specify the second one.
>> If they are already visible somewhere, that should be neough.
>> If not, "mounting" is the action of taking a device containing
>> a filesystem and attacking it so that the filesystem becomes
>> accessible somewhere.
>>
>> Side note: Give the second "tar" a "v" first, e.g. "dvf" to see
>> the comparison is actually working, then interrypt and run
>> without the "v". Otherwise it is possible that nothing is actually
>> compared if there are problems with the path(s).
> I'm actually a big fan of tar (though you wouldn't have guessed from
> the amount of profanities I uttered at it over the years).
It is one of those Maga-tools that does one thing really, really
well.
> If the
> partitions can be made visible, and they are the file systems that are
> meaningful and navigable by tar, this is a very appealing solution.
> Thanks, I'll try to find out more about these non-letter-drive
> partitions that Toshiba installs on their laptops. I know in concept
> what they are related to (booting & recovery), but I'm still very
> green on the plethora of files systems and such that can occupy the
> partitions.
AndyHancock
Jan 15, 2012, 11:52:55 PM1/15/12
to
On Jan 15, 8:18 pm, Arno <m...@privacy.net> wrote:
Thanks.
About your having done this for years, I get the distinct sense that
you're unix-y. Have you been doing it for weird Windows-based
partitions? Toshiba's 4-partition setup is particularly -- unique.
If you succeeded with Windows, that inspires confidence. Otherwise, I
see a minefield of stuff that I don't know about the different types
of partitions and file systems out there, and which ones can be
properly seen by tar.
About your having done this for years, I get the distinct sense that
you're unix-y. Have you been doing it for weird Windows-based
partitions? Toshiba's 4-partition setup is particularly -- unique.
If you succeeded with Windows, that inspires confidence. Otherwise, I
see a minefield of stuff that I don't know about the different types
of partitions and file systems out there, and which ones can be
properly seen by tar.
AndyHancock
Jan 17, 2012, 12:49:15 AM1/17/12
to
deal with files and folders, which are constructs of file systems.
Three of the four partitions I'll be cloning don't have NTFS (don't
know what they have -- one is for booting among other things, two are
"Hidden Installed File Systems") nor letter drives. I don't believe
that I can even mount them or assign a drive letter to them. Surfing
gives me the impression (only an impression) that you can't mount non-
NTFS, and "you cannot assign a drive letter to an Original Equipment
Manufacturer (OEM) partition or any GUID Partition Table (GPT)
partition other than a basic MSDATA partition".
Sigh. Maybe it's time to give up on this.
Rod Speed
Jan 17, 2012, 3:50:20 AM1/17/12
to
AndyHancock wrote
> AndyHancock <andymhanc...@gmail.com> wrote
>> Arno <m...@privacy.net> wrote
>>> AndyHancock <andymhanc...@gmail.com> wrote
Nope.
> Most comparison apps deal with files and folders, which are constructs
> of file systems. Three of the four partitions I'll be cloning don't have NTFS
Doesnt matter, you should still be able to do a binary compare
and then see if the recovery ops still work with the clone.
> (don't know what they have
If they arent NTFS, they are likely FAT.
> -- one is for booting among other things, two are
> "Hidden Installed File Systems") nor letter drives.
Doesnt matter with a binary compare.
> I don't believe that I can even mount them or assign a drive letter to them.
Doesnt matter with a binary compare.
> Surfing gives me the impression (only an impression) that you can't mount non-NTFS,
Corse you can with FAT partitions.
> and "you cannot assign a drive letter to an Original Equipment
> Manufacturer (OEM) partition or any GUID Partition Table (GPT)
> partition other than a basic MSDATA partition".
You dont need to with a binary compare.
> Sigh. Maybe it's time to give up on this.
No need to on seeing if the restore ops work with the clone.
> AndyHancock <andymhanc...@gmail.com> wrote
>> Arno <m...@privacy.net> wrote
>>> AndyHancock <andymhanc...@gmail.com> wrote
> Most comparison apps deal with files and folders, which are constructs
> of file systems. Three of the four partitions I'll be cloning don't have NTFS
and then see if the recovery ops still work with the clone.
> (don't know what they have
> -- one is for booting among other things, two are
> "Hidden Installed File Systems") nor letter drives.
> I don't believe that I can even mount them or assign a drive letter to them.
> Surfing gives me the impression (only an impression) that you can't mount non-NTFS,
> and "you cannot assign a drive letter to an Original Equipment
> Manufacturer (OEM) partition or any GUID Partition Table (GPT)
> partition other than a basic MSDATA partition".
> Sigh. Maybe it's time to give up on this.
Yousuf Khan
Jan 17, 2012, 4:00:53 AM1/17/12
to
On 15/01/2012 8:39 AM, Arno wrote:
> In comp.sys.ibm.pc.hardware.storage AndyHancock<andymh...@gmail.com> wrote:
>> I just cloned two partitions from a resident HDD to an auxiliary
>> Momentus XL HDD in an enclosure that is connected to the computer via
>> eSATA. Is there a way to compare each cloned partition with its
>> original for integrity? If this were just a file, I'd use a unix/
>> cygwin utility like diff or cmp. However, it is a partition.
>
> If it is a bit-wise exact clone, cmp still works, but doing
> md5sum or sha1sum on the whole partitions is faster.
> On mimatch it tells you almost nothing though.
>
> Or you can mount both, and do a file-tree comparison.
> I do the following for that:
>
> cd<dir1>; tar cf - .| (cd<dir2>; tar df -)
>
> Arno
I use an utility called Duplicate Cleaner (http://is.gd/7XlwgM) for file
> In comp.sys.ibm.pc.hardware.storage AndyHancock<andymh...@gmail.com> wrote:
>> I just cloned two partitions from a resident HDD to an auxiliary
>> Momentus XL HDD in an enclosure that is connected to the computer via
>> eSATA. Is there a way to compare each cloned partition with its
>> original for integrity? If this were just a file, I'd use a unix/
>> cygwin utility like diff or cmp. However, it is a partition.
>
> If it is a bit-wise exact clone, cmp still works, but doing
> md5sum or sha1sum on the whole partitions is faster.
> On mimatch it tells you almost nothing though.
>
> Or you can mount both, and do a file-tree comparison.
> I do the following for that:
>
> cd<dir1>; tar cf - .| (cd<dir2>; tar df -)
>
> Arno
comparisons. I like it because it offers a range of options for content
comparison (byte-by-byte, MD5, SHA-1, & SHA-256). I find the fastest
method is usually byte-by-byte, as it'll stop the comparison the moment
it finds a mismatched byte and not bother with the rest of the
comparison of those files. The other methods would involve taking a full
reading the whole file and then generating a checksum at the end.
Yousuf Khan
Mark F
Jan 17, 2012, 3:27:34 PM1/17/12
to
On Tue, 17 Jan 2012 19:50:20 +1100, "Rod Speed"
<rod.sp...@gmail.com> wrote in part:
> AndyHancock wrote
> > AndyHancock <andymhanc...@gmail.com> wrote
> >> Arno <m...@privacy.net> wrote
> >>> AndyHancock <andymhanc...@gmail.com> wrote
> >>>> Arno <m...@privacy.net> wrote
>
...
>
by default.
Usually you don't need a bit-by-bit copy, and the logical copy
that is done is fine. In fact, if you are copying to a disk
of a different size a bit-by-but copy may not fit or have other
issues, such as unusable space or a partition that has to be at the
end of the drive isn't.
For bit-by-bit copies, I'm sure some Unix utility that has already
been mentioned will do a compare.
For logical copy compares I use Super Flexible File Synchronizer, for
purchase product from:
http://www.superflexible.com/
Only compares one partition at a time and doesn't compare the
partition table.
Doesn't compare everything that might be needed and you might find
problems with some files that are hidden from access. (Norton
AntiVirus Hide some stuff. Using the proper account might get around
this particular problem.)
Also, I think Windows encrypted files probably can't be accessed
on system disks from another system or [probably] on a clone of the
current system.
Note that the current system partition is a moving target.
Note that mounting a partition probably changes the partition in a
few places. (I've used a read only adaptor for drives and NTFS
didn't complain, but I didn't have two adaptors or the time to
try comparing a clone with an original system disk.
Note that NTFS partitions have journals that may be handled
differently by different clone programs. I tried some version of
Acronis True Image and a different clone program and found some
differences when I did the compare that either were due to bugs
in the clone operation or a different handling of the journal.
(The differences were all related to files that I didn't care about
and COULD have been due to journalling.)
Super Flexible File Synchronizer (SFFS) is both faster than any other
program that I tried and had few issues than any other program that I
tried except for bit-by-bit compares.
SFFS checks at least one NTFS date field that Explorer doesn't
display, but I don't know if it checks all of the date fields that
NTFS maintains.
SFFS won't check allocated but unused space.
(Salty Brine's FolderMatch is easier to use, but is slower and doesn't
see some files that SFFS sees. However, FolderMatch does better at
comparing files that are not expected to match exactly and is easier
to use, so I recommend buying FolderMatch in addition to SFFS.)
<rod.sp...@gmail.com> wrote in part:
> AndyHancock wrote
> > AndyHancock <andymhanc...@gmail.com> wrote
> >> Arno <m...@privacy.net> wrote
> >>> AndyHancock <andymhanc...@gmail.com> wrote
> >>>> Arno <m...@privacy.net> wrote
>
...
>
> >>>> If the partitions can be made visible, and they are the file systems that
> >>>> are meaningful and navigable by tar, this is a very appealing solution.
>
> >>> I have been using it for years.
>
> >>>> Thanks, I'll try to find out more about these non-letter-drive
> >>>> partitions that Toshiba installs on their laptops. I know in
> >>>> concept what they are related to (booting & recovery), but I'm
> >>>> still very green on the plethora of files systems and such that
> >>>> can occupy the partitions.
Many disk "clone" programs don't actually make bit-by-bit copies
> >>>> are meaningful and navigable by tar, this is a very appealing solution.
>
> >>> I have been using it for years.
>
> >>>> Thanks, I'll try to find out more about these non-letter-drive
> >>>> partitions that Toshiba installs on their laptops. I know in
> >>>> concept what they are related to (booting & recovery), but I'm
> >>>> still very green on the plethora of files systems and such that
> >>>> can occupy the partitions.
by default.
Usually you don't need a bit-by-bit copy, and the logical copy
that is done is fine. In fact, if you are copying to a disk
of a different size a bit-by-but copy may not fit or have other
issues, such as unusable space or a partition that has to be at the
end of the drive isn't.
For bit-by-bit copies, I'm sure some Unix utility that has already
been mentioned will do a compare.
For logical copy compares I use Super Flexible File Synchronizer, for
purchase product from:
http://www.superflexible.com/
Only compares one partition at a time and doesn't compare the
partition table.
Doesn't compare everything that might be needed and you might find
problems with some files that are hidden from access. (Norton
AntiVirus Hide some stuff. Using the proper account might get around
this particular problem.)
Also, I think Windows encrypted files probably can't be accessed
on system disks from another system or [probably] on a clone of the
current system.
Note that the current system partition is a moving target.
Note that mounting a partition probably changes the partition in a
few places. (I've used a read only adaptor for drives and NTFS
didn't complain, but I didn't have two adaptors or the time to
try comparing a clone with an original system disk.
Note that NTFS partitions have journals that may be handled
differently by different clone programs. I tried some version of
Acronis True Image and a different clone program and found some
differences when I did the compare that either were due to bugs
in the clone operation or a different handling of the journal.
(The differences were all related to files that I didn't care about
and COULD have been due to journalling.)
Super Flexible File Synchronizer (SFFS) is both faster than any other
program that I tried and had few issues than any other program that I
tried except for bit-by-bit compares.
SFFS checks at least one NTFS date field that Explorer doesn't
display, but I don't know if it checks all of the date fields that
NTFS maintains.
SFFS won't check allocated but unused space.
(Salty Brine's FolderMatch is easier to use, but is slower and doesn't
see some files that SFFS sees. However, FolderMatch does better at
comparing files that are not expected to match exactly and is easier
to use, so I recommend buying FolderMatch in addition to SFFS.)
AndyHancock
Jan 18, 2012, 12:19:20 AM1/18/12
to
>> Looks like the problem may be insurmountable.
>
> Nope.
>
>> Most comparison apps deal with files and folders, which are
>> constructs of file systems. Three of the four partitions I'll be
>> cloning don't have NTFS
>
> Doesnt matter, you should still be able to do a binary compare and
> then see if the recovery ops still work with the clone.
>
>> (don't know what they have
>
> If they arent NTFS, they are likely FAT.
>
>> -- one is for booting among other things, two are "Hidden Installed
>> File Systems") nor letter drives.
>
> Doesnt matter with a binary compare.
>
>> I don't believe that I can even mount them or assign a drive letter
>> to them.
>
> Doesnt matter with a binary compare.
>
>> Surfing gives me the impression (only an impression) that you can't
>> mount non-NTFS,
>
> Corse you can with FAT partitions.
>
>> and "you cannot assign a drive letter to an Original Equipment
>> Manufacturer (OEM) partition or any GUID Partition Table (GPT)
>> partition other than a basic MSDATA partition".
>
> You dont need to with a binary compare.
>
>> Sigh. Maybe it's time to give up on this.
>
> No need to on seeing if the restore ops work with the clone.
I can try recovery ops (I will). But binary compare of files requires
>
> Nope.
>
>> Most comparison apps deal with files and folders, which are
>> constructs of file systems. Three of the four partitions I'll be
>> cloning don't have NTFS
>
> Doesnt matter, you should still be able to do a binary compare and
> then see if the recovery ops still work with the clone.
>
>> (don't know what they have
>
> If they arent NTFS, they are likely FAT.
>
>> -- one is for booting among other things, two are "Hidden Installed
>> File Systems") nor letter drives.
>
> Doesnt matter with a binary compare.
>
>> I don't believe that I can even mount them or assign a drive letter
>> to them.
>
> Doesnt matter with a binary compare.
>
>> Surfing gives me the impression (only an impression) that you can't
>> mount non-NTFS,
>
> Corse you can with FAT partitions.
>
>> and "you cannot assign a drive letter to an Original Equipment
>> Manufacturer (OEM) partition or any GUID Partition Table (GPT)
>> partition other than a basic MSDATA partition".
>
> You dont need to with a binary compare.
>
>> Sigh. Maybe it's time to give up on this.
>
> No need to on seeing if the restore ops work with the clone.
accessing the files, which requires mounting (doesn't it?), and from
http://www.win.tue.nl/~aeb/partitions/partition_types-1.html it seems
the partition type code for IFS differs from the various FAT file
systems. Just wondering if you might have encountered this kind of
issue before.
Hey, I'm new to this stuff, so I could be way off...but how would you
mount it?
On the other hand, if you mean binary compare of the partition rather
than individual files, Mark mentioned in this thread that cloning
often isn't bit-by bit (though I'm sure binary files match bit-by-
bit). However, even before he posted, I suspected that the partition
isn't a bit-by-bit copy because of partition shrinkage.
If any of this seems off the mark, thanks if you could illuminate.
AndyHancock
Jan 18, 2012, 12:30:10 AM1/18/12
to
On Jan 17, 3:27 pm, Mark F <mark53...@gmail.com> wrote:
> AndyHancock wrote
> For bit-by-bit copies, I'm sure some Unix utility that has already
> been mentioned will do a compare.
>
> For logical copy compares I use Super Flexible File Synchronizer,
> for purchase product from: http://www.superflexible.com/
>
> Only compares one partition at a time and doesn't compare the
> partition table.
>
> Doesn't compare everything that might be needed and you might find
> problems with some files that are hidden from access. (Norton
> AntiVirus Hide some stuff. Using the proper account might get around
> this particular problem.)
>
> Also, I think Windows encrypted files probably can't be accessed on
> system disks from another system or [probably] on a clone of the
> current system.
In your experience with SFFS, do you actually have to mount the
partition?
The problem I see is that the partition type is 17 (hex), which
http://www.win.tue.nl/~aeb/partitions/partition_types-1.html says is
IFS. FAT & NTFS file systems seem to have different codes.
> Note that the current system partition is a moving target.
Understood. I was going to expect differences, and expect to not know
whether they were significant. I guess I would look for obviously bad
discrepancies, ignoring the ones I didn't understand.
> Note that mounting a partition probably changes the partition in a
> few places. (I've used a read only adaptor for drives and NTFS
> didn't complain, but I didn't have two adaptors or the time to try
> comparing a clone with an original system disk.
The possibility of inadvertently changing the partition through
mounting or letter-drive assignment did occur to me, which is one
reason why I didn't want to look into ways of forcibly mounting or
letter-driving a partition with an unknown partition type. I'm not
sure if I would break their function.
> Note that NTFS partitions have journals that may be handled
> differently by different clone programs. I tried some version of
> Acronis True Image and a different clone program and found some
> differences when I did the compare that either were due to bugs in
> the clone operation or a different handling of the journal. (The
> differences were all related to files that I didn't care about and
> COULD have been due to journalling.)
> Super Flexible File Synchronizer (SFFS) is both faster than any
> other program that I tried and had few issues than any other program
> that I tried except for bit-by-bit compares.
>
> SFFS checks at least one NTFS date field that Explorer doesn't
> display, but I don't know if it checks all of the date fields that
> NTFS maintains.
>
> SFFS won't check allocated but unused space.
>
> (Salty Brine's FolderMatch is easier to use, but is slower and
> doesn't see some files that SFFS sees. However, FolderMatch does
> better at comparing files that are not expected to match exactly and
> is easier to use, so I recommend buying FolderMatch in addition to
> SFFS.)
Thanks for that, Mark. I'm going to consider it in light of the
uncertainties I describe above. I still feel like leaning on the side
of not mucking with those partitions of unknown type.
> AndyHancock wrote
>> Thanks, I'll try to find out more about these non-letter-drive
>> partitions that Toshiba installs on their laptops. I know in
>> concept what they are related to (booting & recovery), but I'm
>> still very green on the plethora of files systems and such that can
>> occupy the partitions.
>
> Many disk "clone" programs don't actually make bit-by-bit copies by
> default.
>
> Usually you don't need a bit-by-bit copy, and the logical copy that
> is done is fine. In fact, if you are copying to a disk of a
> different size a bit-by-but copy may not fit or have other issues,
> such as unusable space or a partition that has to be at the end of
> the drive isn't.
Indeed. Ghost 15's Copy Disk will clone to a smaller partition.
>> partitions that Toshiba installs on their laptops. I know in
>> concept what they are related to (booting & recovery), but I'm
>> still very green on the plethora of files systems and such that can
>> occupy the partitions.
>
> Many disk "clone" programs don't actually make bit-by-bit copies by
> default.
>
> Usually you don't need a bit-by-bit copy, and the logical copy that
> is done is fine. In fact, if you are copying to a disk of a
> different size a bit-by-but copy may not fit or have other issues,
> such as unusable space or a partition that has to be at the end of
> the drive isn't.
> For bit-by-bit copies, I'm sure some Unix utility that has already
> been mentioned will do a compare.
>
> For logical copy compares I use Super Flexible File Synchronizer,
> for purchase product from: http://www.superflexible.com/
>
> Only compares one partition at a time and doesn't compare the
> partition table.
>
> Doesn't compare everything that might be needed and you might find
> problems with some files that are hidden from access. (Norton
> AntiVirus Hide some stuff. Using the proper account might get around
> this particular problem.)
>
> Also, I think Windows encrypted files probably can't be accessed on
> system disks from another system or [probably] on a clone of the
> current system.
partition?
The problem I see is that the partition type is 17 (hex), which
http://www.win.tue.nl/~aeb/partitions/partition_types-1.html says is
IFS. FAT & NTFS file systems seem to have different codes.
> Note that the current system partition is a moving target.
whether they were significant. I guess I would look for obviously bad
discrepancies, ignoring the ones I didn't understand.
> Note that mounting a partition probably changes the partition in a
> few places. (I've used a read only adaptor for drives and NTFS
> didn't complain, but I didn't have two adaptors or the time to try
> comparing a clone with an original system disk.
mounting or letter-drive assignment did occur to me, which is one
reason why I didn't want to look into ways of forcibly mounting or
letter-driving a partition with an unknown partition type. I'm not
sure if I would break their function.
> Note that NTFS partitions have journals that may be handled
> differently by different clone programs. I tried some version of
> Acronis True Image and a different clone program and found some
> differences when I did the compare that either were due to bugs in
> the clone operation or a different handling of the journal. (The
> differences were all related to files that I didn't care about and
> COULD have been due to journalling.)
> Super Flexible File Synchronizer (SFFS) is both faster than any
> other program that I tried and had few issues than any other program
> that I tried except for bit-by-bit compares.
>
> SFFS checks at least one NTFS date field that Explorer doesn't
> display, but I don't know if it checks all of the date fields that
> NTFS maintains.
>
> SFFS won't check allocated but unused space.
>
> (Salty Brine's FolderMatch is easier to use, but is slower and
> doesn't see some files that SFFS sees. However, FolderMatch does
> better at comparing files that are not expected to match exactly and
> is easier to use, so I recommend buying FolderMatch in addition to
> SFFS.)
uncertainties I describe above. I still feel like leaning on the side
of not mucking with those partitions of unknown type.
AndyHancock
Jan 18, 2012, 12:33:51 AM1/18/12
to
On Jan 17, 4:00 am, Yousuf Khan <bbb...@spammenot.yahoo.com> wrote:
> On 15/01/2012 8:39 AM, Arno wrote:
>
>
>
>
>
>
>
>
>
> > In comp.sys.ibm.pc.hardware.storage AndyHancock<andymhanc...@gmail.com> wrote:
> On 15/01/2012 8:39 AM, Arno wrote:
>
>
>
>
>
>
>
>
>
I believe that the concerns about the unknown partition type that I
describe in my reply to Mark F apply. Would you be able to respond to
those? Much appreciated.
Rod Speed
Jan 18, 2012, 1:04:58 AM1/18/12
to
AndyHancock wrote
Fine, thats all I meant there, that if you do that, and check that
the OS partition does boot fine and works fine, there is no real
need to do a binary compare.
> But binary compare of files requires accessing the files,
Not with the two non system partitions that you arent going to
change the size of, just a bit by bit compare is all you need to do
for a compare of those, given that you do a bit by bit clone of them.
> which requires mounting (doesn't it?),
Depends on what you mean by mounting.
Yes if you are doing that compare from a Linux live CD etc.
But not necessarily if you are doing the compare from something else
like a Win bootable CD etc.
> and from http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
> it seems the partition type code for IFS differs from the various FAT file systems.
> Just wondering if you might have encountered this kind of issue before.
I dont bother to do binary compares of cloned Win system
partitions, I just boot them and see if they work fine after
having the cloner do a verify after its just done the clone.
And I clone using what True Image calls its rescue CD which is
actually a bootable linux live CD, so there is no possibility that
Win itself will have changed the original system partition in any
way, because it isnt booted at the the time the cloning is done.
Thats one of its big advantages over Nortons which cant do it like that.
> Hey, I'm new to this stuff, so I could be way off...but how would you mount it?
You dont have to explicitly mount it if you boot a Win live CD and do the
file compare at that level. Not worth bothering with IMO but that approach
would work if you insist on doing a binary compare at the file level.
> On the other hand, if you mean binary compare of the partition
> rather than individual files, Mark mentioned in this thread that
> cloning often isn't bit-by bit
And cant be in your case with the partition you are changing the size of.
> (though I'm sure binary files match bit-by- bit). However,
> even before he posted, I suspected that the partition
> isn't a bit-by-bit copy because of partition shrinkage.
And that is correct. It just isnt possible to do a bit by bit copy if the size is different,
the OS partition does boot fine and works fine, there is no real
need to do a binary compare.
> But binary compare of files requires accessing the files,
change the size of, just a bit by bit compare is all you need to do
for a compare of those, given that you do a bit by bit clone of them.
> which requires mounting (doesn't it?),
Yes if you are doing that compare from a Linux live CD etc.
But not necessarily if you are doing the compare from something else
like a Win bootable CD etc.
> and from http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
> it seems the partition type code for IFS differs from the various FAT file systems.
> Just wondering if you might have encountered this kind of issue before.
partitions, I just boot them and see if they work fine after
having the cloner do a verify after its just done the clone.
And I clone using what True Image calls its rescue CD which is
actually a bootable linux live CD, so there is no possibility that
Win itself will have changed the original system partition in any
way, because it isnt booted at the the time the cloning is done.
Thats one of its big advantages over Nortons which cant do it like that.
> Hey, I'm new to this stuff, so I could be way off...but how would you mount it?
file compare at that level. Not worth bothering with IMO but that approach
would work if you insist on doing a binary compare at the file level.
> On the other hand, if you mean binary compare of the partition
> rather than individual files, Mark mentioned in this thread that
> cloning often isn't bit-by bit
> (though I'm sure binary files match bit-by- bit). However,
> even before he posted, I suspected that the partition
> isn't a bit-by-bit copy because of partition shrinkage.
AndyHancock
Jan 18, 2012, 1:46:35 AM1/18/12
to
On Jan 18, 1:04 am, "Rod Speed" <rod.speed....@gmail.com> wrote:
> AndyHancock wrote
>> Rod Speed <rod.speed....@gmail.com> wrote
>>> AndyHancock wrote
> AndyHancock wrote
>> Rod Speed <rod.speed....@gmail.com> wrote
>>> AndyHancock wrote
>> I can try recovery ops (I will).
>
> Fine, thats all I meant there, that if you do that, and check that
> the OS partition does boot fine and works fine, there is no real
> need to do a binary compare.
>
>> But binary compare of files requires accessing the files,
>
> Not with the two non system partitions that you arent going to
> change the size of, just a bit by bit compare is all you need to do
> for a compare of those, given that you do a bit by bit clone of
> them.
>
>> which requires mounting (doesn't it?),
>
> Depends on what you mean by mounting.
>
> Yes if you are doing that compare from a Linux live CD etc.
>
> But not necessarily if you are doing the compare from something else
> like a Win bootable CD etc.
Hmmm. Can you elaborate on what you mean by a Win bootable CD? What
>
> Fine, thats all I meant there, that if you do that, and check that
> the OS partition does boot fine and works fine, there is no real
> need to do a binary compare.
>
>> But binary compare of files requires accessing the files,
>
> Not with the two non system partitions that you arent going to
> change the size of, just a bit by bit compare is all you need to do
> for a compare of those, given that you do a bit by bit clone of
> them.
>
>> which requires mounting (doesn't it?),
>
> Depends on what you mean by mounting.
>
> Yes if you are doing that compare from a Linux live CD etc.
>
> But not necessarily if you are doing the compare from something else
> like a Win bootable CD etc.
would be on that CD? Does it have a bit-by-bit partition comparison
utility? (ie. ignores the concept of files and a file system)?
>> and
>> fromhttp://www.win.tue.nl/~aeb/partitions/partition_types-1.html it
>> seems the partition type code for IFS differs from the various FAT
>> file systems. Just wondering if you might have encountered this
>> kind of issue before.
>
> I dont bother to do binary compares of cloned Win system partitions,
> I just boot them and see if they work fine after having the cloner
> do a verify after its just done the clone.
>
> And I clone using what True Image calls its rescue CD which is
> actually a bootable linux live CD, so there is no possibility that
> Win itself will have changed the original system partition in any
> way, because it isnt booted at the the time the cloning is done.
>
> Thats one of its big advantages over Nortons which cant do it like
> that.
Well....I've already bought Norton. I have to stop flipping between
>> file systems. Just wondering if you might have encountered this
>> kind of issue before.
>
> I dont bother to do binary compares of cloned Win system partitions,
> I just boot them and see if they work fine after having the cloner
> do a verify after its just done the clone.
>
> And I clone using what True Image calls its rescue CD which is
> actually a bootable linux live CD, so there is no possibility that
> Win itself will have changed the original system partition in any
> way, because it isnt booted at the the time the cloning is done.
>
> Thats one of its big advantages over Nortons which cant do it like
> that.
apps. I first installed Paragon Free, then I bought Migrate OS to SSD
(returned it).
>> Hey, I'm new to this stuff, so I could be way off...but how would
>> you mount it?
>
> You dont have to explicitly mount it if you boot a Win live CD and
> do the file compare at that level. Not worth bothering with IMO but
> that approach would work if you insist on doing a binary compare at
> the file level.
>
>> On the other hand, if you mean binary compare of the partition
>> rather than individual files, Mark mentioned in this thread that
>> cloning often isn't bit-by bit
>
> And cant be in your case with the partition you are changing the
> size of.
>> (though I'm sure binary files match bit-by- bit). However, even
>> before he posted, I suspected that the partition isn't a bit-by-bit
>> copy because of partition shrinkage.
>
> And that is correct. It just isnt possible to do a bit by bit copy
> if the size is different,
and 4 contain info to make recovery discs & to restore to factory
state without the discs. I guess I can test both functions by making
a set of discs and recovering from them, as well as by trying to
recover without the discs. Boy, that's a hassle (though you did say
you don't bother with this stuff). If that fails, it might be due to
an imperfect cloning of partitions 3 or 4, or it might be due to the
fact that the functions they serve only work if the partition starting
locations don't change (and they will, since partition 2 will
shrink). More likely the latter, admittedly.
Rod Speed
Jan 18, 2012, 4:42:30 AM1/18/12
to
AndyHancock wrote
> Rod Speed <rod.speed....@gmail.com> wrote
>> AndyHancock wrote
>>> Rod Speed <rod.speed....@gmail.com> wrote
>>>> AndyHancock wrote
>>> I can try recovery ops (I will).
>> Fine, thats all I meant there, that if you do that, and check that
>> the OS partition does boot fine and works fine, there is no real
>> need to do a binary compare.
>>> But binary compare of files requires accessing the files,
>> Not with the two non system partitions that you arent going to
>> change the size of, just a bit by bit compare is all you need to do
>> for a compare of those, given that you do a bit by bit clone of them.
>>> which requires mounting (doesn't it?),
>> Depends on what you mean by mounting.
>> Yes if you are doing that compare from a Linux live CD etc.
>> But not necessarily if you are doing the compare from something else
>> like a Win bootable CD etc.
> Hmmm. Can you elaborate on what you mean by a Win bootable CD?
Like
> Rod Speed <rod.speed....@gmail.com> wrote
>> AndyHancock wrote
>>> Rod Speed <rod.speed....@gmail.com> wrote
>>>> AndyHancock wrote
>>> I can try recovery ops (I will).
>> Fine, thats all I meant there, that if you do that, and check that
>> the OS partition does boot fine and works fine, there is no real
>> need to do a binary compare.
>>> But binary compare of files requires accessing the files,
>> Not with the two non system partitions that you arent going to
>> change the size of, just a bit by bit compare is all you need to do
>> for a compare of those, given that you do a bit by bit clone of them.
>>> which requires mounting (doesn't it?),
>> Depends on what you mean by mounting.
>> Yes if you are doing that compare from a Linux live CD etc.
>> But not necessarily if you are doing the compare from something else
>> like a Win bootable CD etc.
> Hmmm. Can you elaborate on what you mean by a Win bootable CD?
http://www.nu2.nu/bootcd/
> What would be on that CD?
> Does it have a bit-by-bit partition comparison utility?
> (ie. ignores the concept of files and a file system)?
>>> and from
>>> http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
>>> it seems the partition type code for IFS differs from the
>>> various FAT file systems. Just wondering if you might
>>> have encountered this kind of issue before.
>> I dont bother to do binary compares of cloned Win system
>> partitions, I just boot them and see if they work fine after
>> having the cloner do a verify after its just done the clone.
>> And I clone using what True Image calls its rescue CD which is
>> actually a bootable linux live CD, so there is no possibility that
>> Win itself will have changed the original system partition in any
>> way, because it isnt booted at the the time the cloning is done.
>> Thats one of its big advantages over Nortons which cant do it like that.
> Well....I've already bought Norton.
Sure, but it makes more sense to use what works best.
>>> it seems the partition type code for IFS differs from the
>>> various FAT file systems. Just wondering if you might
>>> have encountered this kind of issue before.
>> I dont bother to do binary compares of cloned Win system
>> partitions, I just boot them and see if they work fine after
>> having the cloner do a verify after its just done the clone.
>> And I clone using what True Image calls its rescue CD which is
>> actually a bootable linux live CD, so there is no possibility that
>> Win itself will have changed the original system partition in any
>> way, because it isnt booted at the the time the cloning is done.
>> Thats one of its big advantages over Nortons which cant do it like that.
> Well....I've already bought Norton.
> I have to stop flipping between apps.
> I first installed Paragon Free, then I bought Migrate OS to SSD (returned it).
>>> Hey, I'm new to this stuff, so I could be way off...but how would you mount it?
>> You dont have to explicitly mount it if you boot a Win live CD and do the
>> file compare at that level. Not worth bothering with IMO but that approach
>> would work if you insist on doing a binary compare at the file level.
>>> On the other hand, if you mean binary compare of the partition
>>> rather than individual files, Mark mentioned in this thread that
>>> cloning often isn't bit-by bit
>> And cant be in your case with the partition you are changing the size of.
> Will the bit-by-bit comparison by the Win Live CD still come up clean?
>>> (though I'm sure binary files match bit-by- bit). However,
>>> even before he posted, I suspected that the partition isn't
>>> a bit-by-bit copy because of partition shrinkage.
>> And that is correct. It just isnt possible to do a bit by bit copy
>> if the size is different,
> Booting will verify partitions 1 and 2.
> I'm told that partitions 3 and 4 contain info to make recovery
> discs & to restore to factory state without the discs.
they do what they are supposed to do as well as the originals do.
> I guess I can test both functions by making a set of discs and recovering
> from them, as well as by trying to recover without the discs.
> Boy, that's a hassle
> (though you did say you don't bother with this stuff).
> If that fails, it might be due to an imperfect cloning of partitions 3 or 4,
> or it might be due to the fact that the functions they serve
> only work if the partition starting locations don't change
> (and they will, since partition 2 will shrink).
have been done so crudely that their locaition is crucials.
You do then know that your approach of cloning to a smaller drive isnt viable.
> More likely the latter, admittedly.
AndyHancock
Jan 19, 2012, 12:28:25 AM1/19/12
to
I'm no longer looking for the best solution (actually, I don't think I
ever was), just one that is simple and works. Others may be better,
but I'm willing to forgo that if it means spending significantly more
time getting to it (including returning products and trialing others).
I looked up the bootable CD, and I don't mean to sound unappreciative
of your good info, but I'm going to see what is viable without getting
into new territory.
But ignoring that [ ;) ], you said I have to put a utility on it that
does bit-by-bit compare. I just re-read your previous post and it's
beginning to click. The sizes of partitions 3 and 4 don't change, so
are you implying that every bit in every sector of the cloned
partition will match the corresponding bit and sector of the
original? Mark mentioned that cloning doesn't always happen bit-by-
bit, but in light of the above, does that mean his comment only
applies when partition sizes change?
ever was), just one that is simple and works. Others may be better,
but I'm willing to forgo that if it means spending significantly more
time getting to it (including returning products and trialing others).
I looked up the bootable CD, and I don't mean to sound unappreciative
of your good info, but I'm going to see what is viable without getting
into new territory.
But ignoring that [ ;) ], you said I have to put a utility on it that
does bit-by-bit compare. I just re-read your previous post and it's
beginning to click. The sizes of partitions 3 and 4 don't change, so
are you implying that every bit in every sector of the cloned
partition will match the corresponding bit and sector of the
original? Mark mentioned that cloning doesn't always happen bit-by-
bit, but in light of the above, does that mean his comment only
applies when partition sizes change?
Yousuf Khan
Jan 19, 2012, 11:37:35 AM1/19/12
to
On 18/01/2012 12:33 AM, AndyHancock wrote:
> I believe that the concerns about the unknown partition type that I
> describe in my reply to Mark F apply. Would you be able to respond to
> those? Much appreciated.
Well, my experience with disk imaging comes from using Macrium Reflect,
> I believe that the concerns about the unknown partition type that I
> describe in my reply to Mark F apply. Would you be able to respond to
> those? Much appreciated.
others are familiar with Acronis True Image, etc. For the most part,
when imaging is done (rather than normal backup), it's because certain
files are position dependent. There may only be one or two files in the
entire file system that are position dependent (usually system boot
files), and without some kind of an attribute saying a file is position
dependent, the image makes all of them positional. The actual contents
will remain identical whether you use traditional backup vs. imaging,
but imaging saves the positional information.
Now, most imaging these days are "smart" meaning that they don't bother
copying the contents of empty blocks or clusters, just ones with files
on them. When the imager then copies the contents to its archive file,
it stores them within its archive in its own internal format. When you
mount the image as a virtual disk, it'll get mounted as the format the
imager had saved it to. It may be NTFS, or FAT, or something else entire
proprietary to the imager. It doesn't matter, the file contents will be
identical. Positional information on the other hand would probably
require the imager's own restore option to restore.
Yousuf Khan
Rod Speed
Jan 19, 2012, 2:27:24 PM1/19/12
to
AndyHancock wrote:
> I'm no longer looking for the best solution (actually, I don't think I
> ever was), just one that is simple and works. Others may be better,
> but I'm willing to forgo that if it means spending significantly more
> time getting to it (including returning products and trialing others).
Sure, like I said, I wouldnt bother personally, I'd just check that the
> I'm no longer looking for the best solution (actually, I don't think I
> ever was), just one that is simple and works. Others may be better,
> but I'm willing to forgo that if it means spending significantly more
> time getting to it (including returning products and trialing others).
cloned Win partition does work properly, because it isnt really feasible
to do a comparision when the cloning is done at the Win level and so
you will inevitably see some changes happen during and after the
cloning has been completed, before you can do a binary compare.
And its so much easier to just check if the restore partitions do what
they are supposed to do rather than do a binary compare of those too.
> I looked up the bootable CD, and I don't mean to sound
> unappreciative of your good info, but I'm going to see
> what is viable without getting into new territory.
You just asked what I meant by a Win Live CD, thats one form of that.
> But ignoring that [ ;) ], you said I have to put a utility on it that
> does bit-by-bit compare. I just re-read your previous post and it's
> beginning to click. The sizes of partitions 3 and 4 don't change,
> so are you implying that every bit in every sector of the cloned
> partition will match the corresponding bit and sector of the original?
The cloner has no alternative with a file system it doesnt understand.
Its less clear if it does understand the file system those use, but
you can always force a bit by bit clone with any decent cloner.
> Mark mentioned that cloning doesn't always happen bit-by-bit,
> but in light of the above, does that mean his
> comment only applies when partition sizes change?
system that the cloner understands, because bit by bit cloning isnt
as efficient as normal cloning and so it normally has to be specified
that you want a bit by bit clone if you want one, except with the
crudest cloners than can only do a bit by bit clone.
Rod Speed
Jan 19, 2012, 2:34:48 PM1/19/12
to
Yousuf Khan wrote
the partition size does not change, and most systems use the one
approach for all cloning unless you specify a bit by bit clone be done,
just because that allows the single approach which works for both
when they partition size changes, and when it doesnt. There is no
point in handling the clone when the size doesnt change specially,
when you also offer a bit by bit clone as an option.
Most modern cloners allow allow compression of the image and file
ops on files in the image, and that isnt possible unless the cloner
understands the file system and doesnt do bit by bit clones by default.
> Now, most imaging these days are "smart" meaning that they don't
> bother copying the contents of empty blocks or clusters, just ones
> with files on them.
Yes, thats the other reason why they dont bother to preserve position.
> When the imager then copies the contents to its archive file, it stores them within its archive in its own internal
> format. When you mount the image as a virtual disk, it'll get mounted as the format the imager had saved it to. It may
> be NTFS, or FAT, or something else entire proprietary to the imager. It doesn't matter, the file contents will be
> identical. Positional information on the other hand would probably require the imager's own restore option to restore.
Most dont even preserve file positions on a restore.
> AndyHancock wrote
>> I believe that the concerns about the unknown partition type that I describe in my reply to Mark F apply. Would you
>> be able to respond to those? Much appreciated.
> Well, my experience with disk imaging comes from using Macrium
> Reflect, others are familiar with Acronis True Image, etc. For the
> most part, when imaging is done (rather than normal backup), it's
> because certain files are position dependent. There may only be one4
>> I believe that the concerns about the unknown partition type that I describe in my reply to Mark F apply. Would you
>> be able to respond to those? Much appreciated.
> Well, my experience with disk imaging comes from using Macrium
> Reflect, others are familiar with Acronis True Image, etc. For the
> most part, when imaging is done (rather than normal backup), it's
> or two files in the entire file system that are position dependent
> (usually system boot files), and without some kind of an attribute
> saying a file is position dependent, the image makes all of them
> positional. The actual contents will remain identical whether you use
> traditional backup vs. imaging, but imaging saves the positional information.
It doesnt usually, actually. Essentially because its only possible when
> (usually system boot files), and without some kind of an attribute
> saying a file is position dependent, the image makes all of them
> positional. The actual contents will remain identical whether you use
> traditional backup vs. imaging, but imaging saves the positional information.
the partition size does not change, and most systems use the one
approach for all cloning unless you specify a bit by bit clone be done,
just because that allows the single approach which works for both
when they partition size changes, and when it doesnt. There is no
point in handling the clone when the size doesnt change specially,
when you also offer a bit by bit clone as an option.
Most modern cloners allow allow compression of the image and file
ops on files in the image, and that isnt possible unless the cloner
understands the file system and doesnt do bit by bit clones by default.
> Now, most imaging these days are "smart" meaning that they don't
> bother copying the contents of empty blocks or clusters, just ones
> with files on them.
> When the imager then copies the contents to its archive file, it stores them within its archive in its own internal
> format. When you mount the image as a virtual disk, it'll get mounted as the format the imager had saved it to. It may
> be NTFS, or FAT, or something else entire proprietary to the imager. It doesn't matter, the file contents will be
> identical. Positional information on the other hand would probably require the imager's own restore option to restore.
AndyHancock
Jan 20, 2012, 12:07:43 AM1/20/12
to
AndyHancock
Jan 20, 2012, 12:17:27 AM1/20/12
to
Yousuf Khan wrote
the clone to be a drop-in replacement for the resident HDD if the
latter fails.
> Now, most imaging these days are "smart" meaning that they don't
> bother copying the contents of empty blocks or clusters, just ones
> with files on them. When the imager then copies the contents to its
> archive file, it stores them within its archive in its own internal
> format. When you mount the image as a virtual disk, it'll get
> mounted as the format the imager had saved it to. It may be NTFS, or
> FAT, or something else entire proprietary to the imager. It doesn't
> matter, the file contents will be identical. Positional information
> on the other hand would probably require the imager's own restore
> option to restore.
I think this is where the biggest difference lies between images and
clones. There is no codifying disk content in cloning because it has
to function without decoding or restoration.
> Well, my experience with disk imaging comes from using Macrium
> Reflect, others are familiar with Acronis True Image, etc. For the
> most part, when imaging is done (rather than normal backup), it's
> because certain files are position dependent. There may only be one4
> Reflect, others are familiar with Acronis True Image, etc. For the
> most part, when imaging is done (rather than normal backup), it's
> or two files in the entire file system that are position dependent
> (usually system boot files), and without some kind of an attribute
> saying a file is position dependent, the image makes all of them
> positional. The actual contents will remain identical whether you
> use traditional backup vs. imaging, but imaging saves the positional
> information.
I think I have to clarify that I meant cloning, not imaging. I want
> (usually system boot files), and without some kind of an attribute
> saying a file is position dependent, the image makes all of them
> positional. The actual contents will remain identical whether you
> use traditional backup vs. imaging, but imaging saves the positional
> information.
the clone to be a drop-in replacement for the resident HDD if the
latter fails.
> Now, most imaging these days are "smart" meaning that they don't
> bother copying the contents of empty blocks or clusters, just ones
> with files on them. When the imager then copies the contents to its
> archive file, it stores them within its archive in its own internal
> format. When you mount the image as a virtual disk, it'll get
> mounted as the format the imager had saved it to. It may be NTFS, or
> FAT, or something else entire proprietary to the imager. It doesn't
> matter, the file contents will be identical. Positional information
> on the other hand would probably require the imager's own restore
> option to restore.
clones. There is no codifying disk content in cloning because it has
to function without decoding or restoration.
willbill
Jan 20, 2012, 1:52:52 PM1/20/12
to
Thu, 19 Jan 2012 11:37:35 -0500, Yousuf Khan wrote:
> On 18/01/2012 12:33 AM, AndyHancock wrote:
>> I believe that the concerns about the unknown partition type that I
>> describe in my reply to Mark F apply. Would you be able to respond to
>> those? Much appreciated.
> Well, my experience with disk imaging comes from using Macrium Reflect,
> others are familiar with Acronis True Image, etc. For the most part,
> when imaging is done (rather than normal backup), it's because certain
> files are position dependent. There may only be one or two files in the
> entire file system that are position dependent (usually system boot
> files), and without some kind of an attribute saying a file is position
> dependent, the image makes all of them positional. The actual contents
> will remain identical whether you use traditional backup vs. imaging,
> but imaging saves the positional information.
I only boot Acronis True Image Home (ATIH) from
> On 18/01/2012 12:33 AM, AndyHancock wrote:
>> I believe that the concerns about the unknown partition type that I
>> describe in my reply to Mark F apply. Would you be able to respond to
>> those? Much appreciated.
> Well, my experience with disk imaging comes from using Macrium Reflect,
> others are familiar with Acronis True Image, etc. For the most part,
> when imaging is done (rather than normal backup), it's because certain
> files are position dependent. There may only be one or two files in the
> entire file system that are position dependent (usually system boot
> files), and without some kind of an attribute saying a file is position
> dependent, the image makes all of them positional. The actual contents
> will remain identical whether you use traditional backup vs. imaging,
> but imaging saves the positional information.
it's bootable disc, and never load it into Windows.
And only use the clone option (from internal HDD
to temp HDD that I plug in at the side of the PC).
ATIH 2010 used to change the starting location of the
partititions, But ATIH 2011 now keeps the starting
location the same. And AFAIK ATIH 2012 also
does this, but I have no 1st hand experience with
the current 2012 version.
> Now, most imaging these days are "smart" meaning that they don't bother
> copying the contents of empty blocks or clusters, just ones with files
> on them. When the imager then copies the contents to its archive file,
> it stores them within its archive in its own internal format. When you
> mount the image as a virtual disk, it'll get mounted as the format the
> imager had saved it to. It may be NTFS, or FAT, or something else entire
> proprietary to the imager. It doesn't matter, the file contents will be
> identical. Positional information on the other hand would probably
> require the imager's own restore option to restore.
Gparted at: http://www.gparted.org/
It permits one to easily turn on/off the active and boot flags
for partitions. :)
You might also reduce your internal HDD count by 1 and
see if that solves your boot problem. I mean having *6*
internal HDD (are they really all HDD? Or perhaps some
are optical disc drives?)
Meaning it's not a smart thing with an ordinary
desktop mobo. it's the type of thing that is
likely better done with a server type mobo.
Bill
Rod Speed
Jan 20, 2012, 4:49:10 PM1/20/12
to
> it's the type of thing that is likely better done with a server type mobo.
of media on them, particularly recorded TV from FTA and pay TV etc.
I've got that many myself and deliberately chose a decent motherboard
that can handle them because I am too lazy to clean up the files from the
PVR because drives are now so cheap.
AndyHancock
Jan 23, 2012, 12:29:42 AM1/23/12
to
On Jan 20, 4:49 pm, "Rod Speed" <rod.speed....@gmail.com> wrote:
>> You might consider downloading the current free
>> Gparted at:http://www.gparted.org/
>
>> It permits one to easily turn on/off the active and boot flags
>> for partitions. :)
>>
>> You might also reduce your internal HDD count by 1 and
>> see if that solves your boot problem. I mean having *6*
>> internal HDD (are they really all HDD? Or perhaps some
>> are optical disc drives?)
>> Meaning it's not a smart thing with an ordinary desktop mobo.
>
> Thats just plain wrong, it works fine with a properly implemented motherboard.
>
>> it's the type of thing that is likely better done with a server type mobo.
>
> Its nothing like that black and white with plenty having PCs with lots
> of media on them, particularly recorded TV from FTA and pay TV etc.
>
> I've got that many myself and deliberately chose a decent motherboard
> that can handle them because I am too lazy to clean up the files from the
> PVR because drives are now so cheap.
When I surfed the web & asked for suggestions, ATIH & Norton Ghost 15
were the 2 contenders. I had to choose one, and a friend has good
experience with Ghost (albeit many version ago), so I went with that.
I have to stick with one app cuz I keep flipping back and forth and
asking for refunds.
Thanks for the tip about gparted. It's a good feature (turn on/off
active and boot flags). Currently, I remove one of the drives (source
or clone) to prevent conflicts which could change the registry so that
one or both are unbootable.
I'm not sure where the count of 6 HDDs comes from. I only have 2 --
the original HDD, which Toshiba puts 4 partitions on, and the clone
HDD, which resides in an enclosure that connects to the laptop via
eSATA. I also got a DVD drive. That's it.
> willbill wrote:
>>
>> I only boot Acronis True Image Home (ATIH) from
>> it's bootable disc, and never load it into Windows.
>> And only use the clone option (from internal HDD
>> to temp HDD that I plug in at the side of the PC).
>
>> ATIH 2010 used to change the starting location of the
>> partititions, But ATIH 2011 now keeps the starting
>> location the same. And AFAIK ATIH 2012 also
>> does this, but I have no 1st hand experience with
>> the current 2012 version.
<...snip...>
>>
>> I only boot Acronis True Image Home (ATIH) from
>> it's bootable disc, and never load it into Windows.
>> And only use the clone option (from internal HDD
>> to temp HDD that I plug in at the side of the PC).
>
>> ATIH 2010 used to change the starting location of the
>> partititions, But ATIH 2011 now keeps the starting
>> location the same. And AFAIK ATIH 2012 also
>> does this, but I have no 1st hand experience with
>> the current 2012 version.
>> You might consider downloading the current free
>> Gparted at:http://www.gparted.org/
>
>> It permits one to easily turn on/off the active and boot flags
>> for partitions. :)
>>
>> You might also reduce your internal HDD count by 1 and
>> see if that solves your boot problem. I mean having *6*
>> internal HDD (are they really all HDD? Or perhaps some
>> are optical disc drives?)
>> Meaning it's not a smart thing with an ordinary desktop mobo.
>
> Thats just plain wrong, it works fine with a properly implemented motherboard.
>
>> it's the type of thing that is likely better done with a server type mobo.
>
> Its nothing like that black and white with plenty having PCs with lots
> of media on them, particularly recorded TV from FTA and pay TV etc.
>
> I've got that many myself and deliberately chose a decent motherboard
> that can handle them because I am too lazy to clean up the files from the
> PVR because drives are now so cheap.
were the 2 contenders. I had to choose one, and a friend has good
experience with Ghost (albeit many version ago), so I went with that.
I have to stick with one app cuz I keep flipping back and forth and
asking for refunds.
Thanks for the tip about gparted. It's a good feature (turn on/off
active and boot flags). Currently, I remove one of the drives (source
or clone) to prevent conflicts which could change the registry so that
one or both are unbootable.
I'm not sure where the count of 6 HDDs comes from. I only have 2 --
the original HDD, which Toshiba puts 4 partitions on, and the clone
HDD, which resides in an enclosure that connects to the laptop via
eSATA. I also got a DVD drive. That's it.
Rod Speed
Jan 23, 2012, 1:32:42 PM1/23/12
to
AndyHancock wrote
IMO its a bit nutty to limit yourself so much for that reason.
> Thanks for the tip about gparted. It's a good feature (turn on/off
> active and boot flags). Currently, I remove one of the drives (source
> or clone) to prevent conflicts which could change the registry so that
> one or both are unbootable.
> I'm not sure where the count of 6 HDDs comes from.
That was Yousuf's system.
> Thanks for the tip about gparted. It's a good feature (turn on/off
> active and boot flags). Currently, I remove one of the drives (source
> or clone) to prevent conflicts which could change the registry so that
> one or both are unbootable.
> I'm not sure where the count of 6 HDDs comes from.
willbill
Jan 24, 2012, 1:22:03 PM1/24/12
to
Sun, 22 Jan 2012 21:29:42 -0800 (PST), AndyHancock wrote:
> When I surfed the web & asked for suggestions, ATIH & Norton Ghost 15
> were the 2 contenders. I had to choose one, and a friend has good
> experience with Ghost (albeit many version ago), so I went with that.
> I have to stick with one app cuz I keep flipping back and forth and
> asking for refunds.
I see that this is your response to Rod Speed and not directly to me.
> When I surfed the web & asked for suggestions, ATIH & Norton Ghost 15
> were the 2 contenders. I had to choose one, and a friend has good
> experience with Ghost (albeit many version ago), so I went with that.
> I have to stick with one app cuz I keep flipping back and forth and
> asking for refunds.
Rod Speed is one of the few that I have kill filed, but from what
I see of his response (to me? snipped by you) it was decent.
Meaning he's at best annoying, and clearly got mental issue(s);
so his occasional good posts are lesser that the enormous
amount of 4 letter crud that he puts out.
Anyway, how have you liked Ghost 15?
And do you boot the Ghost 15 from the disc
to use it, or load it into Windows?
FWIW I've only booted ATIH 2010 and 2011 from the disc
and never loaded it into Windows. It's been a long time
since I've used Ghost (again only booted from the disc
and not loaded into Windows).
> Thanks for the tip about gparted. It's a good feature (turn on/off
> active and boot flags). Currently, I remove one of the drives (source
> or clone) to prevent conflicts which could change the registry so that
> one or both are unbootable.
Gparted (and other Linux based programs) are now
my preferred partitioning options. :)
> I'm not sure where the count of 6 HDDs comes from. I only have 2 --
> the original HDD, which Toshiba puts 4 partitions on, and the clone
> HDD, which resides in an enclosure that connects to the laptop via
> eSATA. I also got a DVD drive. That's it.
but not directely from above posts.
I posted that comment to him (as well as the suggestion
to reduce his plugged in "HDD" device count by 1,
thinking that that might solve his bios/boot problem.
Still hoping to see a response from him on this. :)
As well as from you on Ghost 15. :)
Bill
AndyHancock
Jan 24, 2012, 8:54:42 PM1/24/12
to
On Jan 23, 1:32 pm, "Rod Speed" <rod.speed....@gmail.com> wrote:
> AndyHancock wrote
to have the two contenders neck-at-neck (or is that neck-to-neck --
nah, that's too much like...a bunch of things that are not really
suited to the topic at hand). And I was tired of buying, trying, and
returning. I figure that no matter what I choose, there will be pro's
and cons, as well as advocates and detractors.
> AndyHancock wrote
>> When I surfed the web & asked for suggestions, ATIH & Norton
>> Ghost 15 were the 2 contenders. I had to choose one, and a
>> friend has good experience with Ghost (albeit many version ago),
>> so I went with that. I have to stick with one app cuz I keep flipping
>> back and forth and asking for refunds.
>
> IMO its a bit nutty to limit yourself so much for that reason.
It does seem that way, I have to admit. But the online material seems
>> Ghost 15 were the 2 contenders. I had to choose one, and a
>> friend has good experience with Ghost (albeit many version ago),
>> so I went with that. I have to stick with one app cuz I keep flipping
>> back and forth and asking for refunds.
>
> IMO its a bit nutty to limit yourself so much for that reason.
to have the two contenders neck-at-neck (or is that neck-to-neck --
nah, that's too much like...a bunch of things that are not really
suited to the topic at hand). And I was tired of buying, trying, and
returning. I figure that no matter what I choose, there will be pro's
and cons, as well as advocates and detractors.
AndyHancock
Jan 24, 2012, 9:05:21 PM1/24/12
to
On Jan 24, 1:22 pm, willbill <posto...@postonNG.net> wrote:
> Sun, 22 Jan 2012 21:29:42 -0800 (PST), AndyHancock wrote:
>
>> When I surfed the web & asked for suggestions, ATIH & Norton Ghost 15
>> were the 2 contenders. I had to choose one, and a friend has good
>> experience with Ghost (albeit many version ago), so I went with that.
>> I have to stick with one app cuz I keep flipping back and forth and
>> asking for refunds.
>
> I see that this is your response to Rod Speed and not directly to me.
> Rod Speed is one of the few that I have kill filed, but from what
> I see of his response (to me? snipped by you) it was decent.
I have no wish to be part of a usenet war. If you don't mind, could
> Sun, 22 Jan 2012 21:29:42 -0800 (PST), AndyHancock wrote:
>
>> When I surfed the web & asked for suggestions, ATIH & Norton Ghost 15
>> were the 2 contenders. I had to choose one, and a friend has good
>> experience with Ghost (albeit many version ago), so I went with that.
>> I have to stick with one app cuz I keep flipping back and forth and
>> asking for refunds.
>
> I see that this is your response to Rod Speed and not directly to me.
> Rod Speed is one of the few that I have kill filed, but from what
> I see of his response (to me? snipped by you) it was decent.
we please keep it professional and focused on the technical topic at
hand? Thanks, appreciate it.
> Anyway, how have you liked Ghost 15?
time to shrink the C-drive partition so that I can clone partitions 3
& 4. That's just a matter of Disk Management, though I have to ensure
4KB boundary alignment -- meaning doing the arithmetic carefully
because both Disk Management and PowerQuest Partition Table Editor
mean MiB and GiB when they say MB and GB.
After that, test of the cloned 4 partitions is still capable of making
recovery discs and also doing discless recovery. If not, there is not
much point in keeping partitions 3 & 4.
Apart from that, I was also going to use my recovery discs to see if
recovery means also recovering partitions 3 & 4, but targeting the
clone HDD. If so, then I'll see if *that* allows the clone to make
recovery discs and/or do discless recovery.
Another thread of activity is to simply run HDD diagnostics and memory
tests to deal with the original boot failures that led to this whole
cloning exercise.
> And do you boot the Ghost 15 from the disc
> to use it, or load it into Windows?
fancy or out of the ordinary (yet).
>> Thanks for the tip about gparted. It's a good feature (turn on/off
>> active and boot flags). Currently, I remove one of the drives (source
>> or clone) to prevent conflicts which could change the registry so that
>> one or both are unbootable.
>
> If I'm included in that thanks, then thanks in return.
AndyHancock
Jan 24, 2012, 9:57:54 PM1/24/12
to
On Jan 24, 9:05 pm, AndyHancock <andymhanc...@gmail.com> wrote:
> Well, it cloned partitions 1 & 2 effortlessly. I have yet to find the
> time to shrink the C-drive partition so that I can clone partitions 3
> & 4. That's just a matter of Disk Management, though I have to ensure
> 4KB boundary alignment -- meaning doing the arithmetic carefully
> because both Disk Management and PowerQuest Partition Table Editor
> mean MiB and GiB when they say MB and GB.
Actually, Disk Managements specifies disk space and partition
> Well, it cloned partitions 1 & 2 effortlessly. I have yet to find the
> time to shrink the C-drive partition so that I can clone partitions 3
> & 4. That's just a matter of Disk Management, though I have to ensure
> 4KB boundary alignment -- meaning doing the arithmetic carefully
> because both Disk Management and PowerQuest Partition Table Editor
> mean MiB and GiB when they say MB and GB.
shrinkage in terms of MiB, so as long as I specify an integer, it will
always be 4KiB aligned.
Yousuf Khan
Jan 25, 2012, 10:53:33 AM1/25/12
to
On 20/01/2012 12:17 AM, AndyHancock wrote:
> Yousuf Khan wrote
>> Well, my experience with disk imaging comes from using Macrium
>> Reflect, others are familiar with Acronis True Image, etc. For the
>> most part, when imaging is done (rather than normal backup), it's
>> because certain files are position dependent. There may only be one4
>> or two files in the entire file system that are position dependent
>> (usually system boot files), and without some kind of an attribute
>> saying a file is position dependent, the image makes all of them
>> positional. The actual contents will remain identical whether you
>> use traditional backup vs. imaging, but imaging saves the positional
>> information.
>
> I think I have to clarify that I meant cloning, not imaging. I want
> the clone to be a drop-in replacement for the resident HDD if the
> latter fails.
I know, but cloning and imaging share a lot in common. Now one cloning
> Yousuf Khan wrote
>> Well, my experience with disk imaging comes from using Macrium
>> Reflect, others are familiar with Acronis True Image, etc. For the
>> most part, when imaging is done (rather than normal backup), it's
>> because certain files are position dependent. There may only be one4
>> or two files in the entire file system that are position dependent
>> (usually system boot files), and without some kind of an attribute
>> saying a file is position dependent, the image makes all of them
>> positional. The actual contents will remain identical whether you
>> use traditional backup vs. imaging, but imaging saves the positional
>> information.
>
> I think I have to clarify that I meant cloning, not imaging. I want
> the clone to be a drop-in replacement for the resident HDD if the
> latter fails.
program that I've used with great success is XXClone. It's not a
traditional cloning program in that it works at the partition level, but
it works at the filesystem level. This means that you can use it to copy
between an NTFS source to a FAT32 destination, or vice-versa. However,
it doesn't do incremental cloning (as far as I know), so everytime you
clone, you're making a full reset. With imaging you can make the
incrementals and differentials.
Yousuf Khan
Rod Speed
Jan 25, 2012, 2:16:34 PM1/25/12
to
Yousuf Khan wrote
which does help with its very fundamental prolem, its MUCH slower
than a mainstream cloner once you have done the original clone.
> so everytime you clone, you're making a full reset.
Fraid not.
> With imaging you can make the incrementals and differentials.
You can with xxclone too.
> AndyHancock wrote
>> Yousuf Khan wrote
>>> Well, my experience with disk imaging comes from using Macrium
>>> Reflect, others are familiar with Acronis True Image, etc. For the
>>> most part, when imaging is done (rather than normal backup), it's
>>> because certain files are position dependent. There may only be one4
>>> or two files in the entire file system that are position dependent
>>> (usually system boot files), and without some kind of an attribute
>>> saying a file is position dependent, the image makes all of them
>>> positional. The actual contents will remain identical whether you
>>> use traditional backup vs. imaging, but imaging saves the positional
>>> information.
>> I think I have to clarify that I meant cloning, not imaging. I want the clone to be a drop-in replacement for the
>> resident HDD if the latter fails.
> I know, but cloning and imaging share a lot in common. Now one cloning
> program that I've used with great success is XXClone. It's not a
> traditional cloning program in that it works at the partition level,
> but it works at the filesystem level. This means that you can use it
> to copy between an NTFS source to a FAT32 destination, or vice-versa.
> However, it doesn't do incremental cloning (as far as I know),
It does actually and that is in fact one of its most dramatic advantages
>> Yousuf Khan wrote
>>> Well, my experience with disk imaging comes from using Macrium
>>> Reflect, others are familiar with Acronis True Image, etc. For the
>>> most part, when imaging is done (rather than normal backup), it's
>>> because certain files are position dependent. There may only be one4
>>> or two files in the entire file system that are position dependent
>>> (usually system boot files), and without some kind of an attribute
>>> saying a file is position dependent, the image makes all of them
>>> positional. The actual contents will remain identical whether you
>>> use traditional backup vs. imaging, but imaging saves the positional
>>> information.
>> I think I have to clarify that I meant cloning, not imaging. I want the clone to be a drop-in replacement for the
>> resident HDD if the latter fails.
> I know, but cloning and imaging share a lot in common. Now one cloning
> program that I've used with great success is XXClone. It's not a
> traditional cloning program in that it works at the partition level,
> but it works at the filesystem level. This means that you can use it
> to copy between an NTFS source to a FAT32 destination, or vice-versa.
> However, it doesn't do incremental cloning (as far as I know),
which does help with its very fundamental prolem, its MUCH slower
than a mainstream cloner once you have done the original clone.
> so everytime you clone, you're making a full reset.
> With imaging you can make the incrementals and differentials.
0 new messages