Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.ibm.pc.hardware.storage > #2377 > unrolled thread

How to compare clone of a partition with source partition

Back to article view | Back to comp.sys.ibm.pc.hardware.storage

Contents

  How to compare clone of a partition with source partition AndyHancock <andymhancock@gmail.com> - 2012-01-14 20:56 -0800
    Re: How to compare clone of a partition with source partition "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-01-15 16:18 +1100
      Re: How to compare clone of a partition with source partition AndyHancock <andymhancock@gmail.com> - 2012-01-14 21:42 -0800
    Re: How to compare clone of a partition with source partition Arno <me@privacy.net> - 2012-01-15 13:39 +0000
      Re: How to compare clone of a partition with source partition AndyHancock <andymhancock@gmail.com> - 2012-01-15 11:43 -0800
        Re: How to compare clone of a partition with source partition Arno <me@privacy.net> - 2012-01-15 20:23 +0000
          Re: How to compare clone of a partition with source partition AndyHancock <andymhancock@gmail.com> - 2012-01-15 12:49 -0800
            Re: How to compare clone of a partition with source partition Arno <me@privacy.net> - 2012-01-16 01:18 +0000
              Re: How to compare clone of a partition with source partition AndyHancock <andymhancock@gmail.com> - 2012-01-15 20:52 -0800
                Re: How to compare clone of a partition with source partition AndyHancock <andymhancock@gmail.com> - 2012-01-16 21:49 -0800
                  Re: How to compare clone of a partition with source partition "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-01-17 19:50 +1100
                    Re: How to compare clone of a partition with source partition Mark F <mark53916@gmail.com> - 2012-01-17 15:27 -0500
                      Re: How to compare clone of a partition with source partition AndyHancock <andymhancock@gmail.com> - 2012-01-17 21:30 -0800
                    Re: How to compare clone of a partition with source partition AndyHancock <andymhancock@gmail.com> - 2012-01-17 21:19 -0800
                      Re: How to compare clone of a partition with source partition "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-01-18 17:04 +1100
                        Re: How to compare clone of a partition with source partition AndyHancock <andymhancock@gmail.com> - 2012-01-17 22:46 -0800
                          Re: How to compare clone of a partition with source partition "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-01-18 20:42 +1100
                            Re: How to compare clone of a partition with source partition AndyHancock <andymhancock@gmail.com> - 2012-01-18 21:28 -0800
                              Re: How to compare clone of a partition with source partition "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-01-20 06:27 +1100
                                Re: How to compare clone of a partition with source partition AndyHancock <andymhancock@gmail.com> - 2012-01-19 21:07 -0800
      Re: How to compare clone of a partition with source partition Yousuf Khan <bbbl67@spammenot.yahoo.com> - 2012-01-17 04:00 -0500
        Re: How to compare clone of a partition with source partition AndyHancock <andymhancock@gmail.com> - 2012-01-17 21:33 -0800
          Re: How to compare clone of a partition with source partition Yousuf Khan <bbbl67@spammenot.yahoo.com> - 2012-01-19 11:37 -0500
            Re: How to compare clone of a partition with source partition "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-01-20 06:34 +1100
            Re: How to compare clone of a partition with source partition AndyHancock <andymhancock@gmail.com> - 2012-01-19 21:17 -0800
              Re: How to compare clone of a partition with source partition Yousuf Khan <bbbl67@spammenot.yahoo.com> - 2012-01-25 10:53 -0500
                Re: How to compare clone of a partition with source partition "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-01-26 06:16 +1100
            Re: How to compare clone of a partition with source partition willbill <postonNG@postonNG.net> - 2012-01-20 12:52 -0600
              Re: How to compare clone of a partition with source partition "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-01-21 08:49 +1100
                Re: How to compare clone of a partition with source partition AndyHancock <andymhancock@gmail.com> - 2012-01-22 21:29 -0800
                  Re: How to compare clone of a partition with source partition "Rod Speed" <rod.speed.aaa@gmail.com> - 2012-01-24 05:32 +1100
                    Re: How to compare clone of a partition with source partition AndyHancock <andymhancock@gmail.com> - 2012-01-24 17:54 -0800
                  Re: How to compare clone of a partition with source partition willbill <postonNG@postonNG.net> - 2012-01-24 12:22 -0600
                    Re: How to compare clone of a partition with source partition AndyHancock <andymhancock@gmail.com> - 2012-01-24 18:05 -0800
                      Re: How to compare clone of a partition with source partition AndyHancock <andymhancock@gmail.com> - 2012-01-24 18:57 -0800

Page 1 of 2  [1] 2  Next page →

#2377 — How to compare clone of a partition with source partition

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.

[toc] | [next] | [standalone]

#2378

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.

[toc] | [prev] | [next] | [standalone]

#2381

On Jan 15, 12:18 am, "Rod Speed" <rod.speed....@gmail.com> wrote:
> 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.

Thanks, Rod.  I replied in that thread.

[toc] | [prev] | [next] | [standalone]

#2383

In comp.sys.ibm.pc.hardware.storage AndyHancock <andymhancock@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


-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@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

[toc] | [prev] | [next] | [standalone]

#2384

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
> > 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?

[toc] | [prev] | [next] | [standalone]

#2386

In comp.sys.ibm.pc.hardware.storage AndyHancock <andymhancock@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
>> > 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 
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).

Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@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

[toc] | [prev] | [next] | [standalone]

#2387

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).  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.

[toc] | [prev] | [next] | [standalone]

#2388

In comp.sys.ibm.pc.hardware.storage AndyHancock <andymhancock@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 ;-)
 
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.

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.

Well, good luck.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@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

[toc] | [prev] | [next] | [standalone]

#2389

On Jan 15, 8:18 pm, Arno <m...@privacy.net> wrote:
> In comp.sys.ibm.pc.hardware.storage AndyHancock <andymhanc...@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 ;-)
>
> 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.
>
> 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.
>
> Well, good luck.

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.

[toc] | [prev] | [next] | [standalone]

#2402

On Jan 15, 11:52 pm, AndyHancock <andymhanc...@gmail.com> wrote:
> On Jan 15, 8:18 pm, Arno <m...@privacy.net> wrote:
>
>
>
>
>
>
>
>
>
> > In comp.sys.ibm.pc.hardware.storage AndyHancock <andymhanc...@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 ;-)
>
> > 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.
>
> > 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.
>
> > Well, good luck.
>
> 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.

Looks like the problem may be insurmountable. 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 (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.

[toc] | [prev] | [next] | [standalone]

#2406

AndyHancock wrote
> AndyHancock <andymhanc...@gmail.com> wrote
>> Arno <m...@privacy.net> wrote
>>> AndyHancock <andymhanc...@gmail.com> wrote
>>>> 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 ;-)

>>> 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.

>>> 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.

>>> Well, good luck.

>> 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.

> 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. 

[toc] | [prev] | [next] | [standalone]

#2411

On Tue, 17 Jan 2012 19:50:20 +1100, "Rod Speed"
<rod.speed.aaa@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
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.)

[toc] | [prev] | [next] | [standalone]

#2418

On Jan 17, 3:27 pm, Mark F <mark53...@gmail.com> wrote:
> 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.

> 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.

[toc] | [prev] | [next] | [standalone]

#2417

On Jan 17, 3:50 am, "Rod Speed" <rod.speed....@gmail.com> wrote:
> AndyHancock wrote
>> 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
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.

[toc] | [prev] | [next] | [standalone]

#2420

AndyHancock wrote
> Rod Speed <rod.speed....@gmail.com> wrote
>> AndyHancock wrote

>>> 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).

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,

> If any of this seems off the mark, thanks if you could illuminate.

[toc] | [prev] | [next] | [standalone]

#2421

On Jan 18, 1:04 am, "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?  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
>> 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
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.  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.

[toc] | [prev] | [next] | [standalone]

#2422

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
http://www.nu2.nu/bootcd/

> What would be on that CD?

A version of Win.

> Does it have a bit-by-bit partition comparison utility?
> (ie. ignores the concept of files and a file system)?

No, but you can add any ute you like.

>>> 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.

> I have to stop flipping between apps.

No you dont until you find one works better than the alternatives.

> I first installed Paragon Free, then I bought Migrate OS to SSD (returned it).

I just use pirated versions until I decide that one works better than the alternatives.

>>> 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?

Yes, with the partitions you dont change the size of like the recovery partitions.

>>> (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.

In fact it will verify all the paritions.

> I'm told that partitions 3 and 4 contain info to make recovery
> discs & to restore to factory state without the discs.

And booting those will show that they have been cloned properly if
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.

Yep.

> Boy, that's a hassle

Not really if you are  properly backed up.

> (though you did say you don't bother with this stuff).

Nope, I said that I dont bother with binary compares of the original and the clone.

> If that fails, it might be due to an imperfect cloning of partitions 3 or 4,

Yes, but thats unllikely if you dont change where they are on the clone.

> or it might be due to the fact that the functions they serve
> only work if the partition starting locations don't change

Yes.

> (and they will, since partition 2 will shrink).

Yes, buit at least you then know that those recovery partitions
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.

One obvious way to see if that is true or not. Yes, it should be unlikely. 

[toc] | [prev] | [next] | [standalone]

#2428

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?

[toc] | [prev] | [next] | [standalone]

#2431

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
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.

Sure, like I said, I dont believe that route is worth bothering with myself.

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?

If the clone is done on a bit by bit basis, yes.

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,

Yes, it usually doesnt with file systems that the cloner understands.

> but in light of the above, does that mean his
> comment only applies when partition sizes change?

No, it also applys when the partition size does change, with a file
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. 

[toc] | [prev] | [next] | [standalone]

#2433

On Jan 19, 2:27 pm, "Rod Speed" <rod.speed....@gmail.com> wrote:
> 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
> 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.
>
> Sure, like I said, I dont believe that route is worth bothering with myself.
>
> 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?
>
> If the clone is done on a bit by bit basis, yes.
>
> 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,
>
> Yes, it usually doesnt with file systems that the cloner understands.
>
>> but in light of the above, does that mean his
>> comment only applies when partition sizes change?
>
> No, it also applys when the partition size does change, with a file
> 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.

OK, got it.  Thanks for all that wisdom.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.ibm.pc.hardware.storage

csiph-web