Verifying "Move/Copy" Activity

Is there a way to "verify" that a moved or copied folder is exactly the
same after completing the function (XP Pro).

Is there a way to "verify" that a moved or copied folder is exactly
the same after completing the function (XP Pro).

Yes. Run a CRC or a HASH on them in both locations. CRC or HASH should
match.
AFAIK there are no problems in XP that way, but there are lots of
CRC/HASH calculators all over the 'net.

On Thu, 08 Jan 2009 05:03:16 -0800, AxeMan wrote:

Is there a way to "verify" that a moved or copied folder is exactly the
same after completing the function (XP Pro).

Is there any reason to think that it wouldn't be?

In article ,
says...
Is there a way to "verify" that a moved or copied folder is exactly
the same after completing the function (XP Pro).

Yes. Run a CRC or a HASH on them in both locations. CRC or HASH
should
match.
AFAIK there are no problems in XP that way, but there are lots of
CRC/HASH calculators all over the 'net.




Thank you. I downloaded a "hash" program (shellex), tested it on a couple
of xferred files and it's great.

But, do you really need it? Under what condition would they differ?
"AxeMan" wrote in message
...
In article ,
says...
Is there a way to "verify" that a moved or copied folder is exactly
the same after completing the function (XP Pro).

Yes. Run a CRC or a HASH on them in both locations. CRC or HASH
should
match.
AFAIK there are no problems in XP that way, but there are lots of
CRC/HASH calculators all over the 'net.




Thank you. I downloaded a "hash" program (shellex), tested it on a couple
of xferred files and it's great.

Unknown wrote:
But, do you really need it? Under what condition would they differ?
"AxeMan" wrote in message
...
In article ,
says...
Is there a way to "verify" that a moved or copied folder is exactly
the same after completing the function (XP Pro).
Yes. Run a CRC or a HASH on them in both locations. CRC or HASH
should
match.
AFAIK there are no problems in XP that way, but there are lots of
CRC/HASH calculators all over the 'net.



Thank you. I downloaded a "hash" program (shellex), tested it on a couple
of xferred files and it's great.




Interesting that you should ask: I'm trying to work out a problem where
the copied file does indeed differ from the source file.

Details as follows:

Originally, I was puzzled that creating an image with True Image version
9.0 (build 3.854) created a corrupted file when the destination of the
image was a USB-attached WD drive while no such problem happened using
the bootable (Linux-based) True Image program and no such problem
happened when the destination was an internal SATA drive.

That led me to copy one good 4.33gb slice of the image to the
USB-attached drive. Running check sums on the original and the copy
showed they were different. No error messages from True Image (other
than reporting corruption in the validation operation) or from Copy and
Paste.

Both the source and destination file systems are NTFS (4K clusters). I'm
running Windows XP Pro SP3. The machine has 3gb of installed memory.
Memory tests show no problems. I've mucked around with updating USB
drivers in SAFE and normal mode.

It appears to be a problem with the USB support but I clearly have not
arrived at an answer. "verify on" doesn't change anything but of course
that just insures that a written file can be read -- not that the data
is what one would expect.

Copying the source file to another internal drive does not exhibit the
same problem. Seems to me that if it were a hardware problem that I'd
have problems with the bootable version of True Image. The problem must
involve the Windows support.

I get different checksums each time I copy the file.

Trust but verify is not a bad rule.

No error message.

Details as follows:

Originally, I was puzzled that creating an image with True Image version
9.0 (build 3.854) created a corrupted file when the destination of the
image was a USB-attached WD drive while no such problem happened using
the bootable (Linux-based) True Image program and no such problem
happened when the destination was an internal SATA drive.

That led me to copy one good 4.33gb slice of the image to the
USB-attached drive. Running check sums on the original and the copy
showed they were different. No error messages from True Image (other
than reporting corruption in the validation operation) or from Copy and
Paste.

Both the source and destination file systems are NTFS (4K clusters). I'm
running Windows XP Pro SP3. The machine has 3gb of installed memory.
Memory tests show no problems. I've mucked around with updating USB
drivers in SAFE and normal mode.

It appears to be a problem with the USB support but I clearly have not
arrived at an answer. "verify on" doesn't change anything but of course
that just insures that a written file can be read -- not that the data
is what one would expect.

Copying the source file to another internal drive does not exhibit the
same problem. Seems to me that if it were a hardware problem that I'd
have problems with the bootable version of True Image. The problem must
involve the Windows support.

I get different checksums each time I copy the file.

Any suggestions for avenues to pursue welcomed...

Bob

Bob wrote:

No error message.

Details as follows:

Originally, I was puzzled that creating an image with True Image version
9.0 (build 3.854) created a corrupted file when the destination of the
image was a USB-attached WD drive while no such problem happened using
the bootable (Linux-based) True Image program and no such problem
happened when the destination was an internal SATA drive.

That led me to copy one good 4.33gb slice of the image to the
USB-attached drive. Running check sums on the original and the copy
showed they were different. No error messages from True Image (other
than reporting corruption in the validation operation) or from Copy and
Paste.

Both the source and destination file systems are NTFS (4K clusters). I'm
running Windows XP Pro SP3. The machine has 3gb of installed memory.
Memory tests show no problems. I've mucked around with updating USB
drivers in SAFE and normal mode.

It appears to be a problem with the USB support but I clearly have not
arrived at an answer. "verify on" doesn't change anything but of course
that just insures that a written file can be read -- not that the data
is what one would expect.

Copying the source file to another internal drive does not exhibit the
same problem. Seems to me that if it were a hardware problem that I'd
have problems with the bootable version of True Image. The problem must
involve the Windows support.

I get different checksums each time I copy the file.

Any suggestions for avenues to pursue welcomed...

Bob

Resolved by mucking around in the USB entries (Device Management) and
applying the latest BIOS upgrade. The former was likely the actual fix.

The message is: If True Image creates corrupted files, you may have a
more serious problem.