?Copy with Verification false alarm?

[MarcinW]

There may be rare cases, when files are same, but comparison (verification) shows them as different. I have a PCI SATA controller and changing some PCI BIOS settings improperly caused rare HDD read errors - reading twice the same, large file, returned sometimes some bytes incorrectly (but without reporting any hardware failure). I found this problem, because some program, after reading the same data file, returned sometimes results other than expected.

[ghisler(Author)]

You should fix your hardware problems, TC cannot know why read errors occur.

[MarcinW]

Well, I was misunderstood. I just wanted to say that the user, that reported problems with verification, might have such kind of a problem.

So there will always be a small group of TC users, that will report problems with verification - but not due to problems with TC itself, but with their hardware. Even the user, that reported his problem, asked: "Could this be a bug in the program or faulty hardware?".

So verification would be useful in this case - it says, that something is wrong, so the user may decide to perform additional hardware tests.

[ghisler(Author)]

Yes, that's why I added some code to write the checksums to the log. But so far no one was able to test it.

For now, I have reactivated the verify function, but I haven't decided yet whether I will keep it in the final version or not.

[MVV]

What are the reasons to remove it from final? There are many users that wanted it for years...

[ghisler(Author)]

The original problem is still not resolved.

[MVV]

Have topic starter contacted you by e-mail? He doesn't answer since October (for more than 2 months) and it is quite strange. And no one still can't reproduce his problem.

[ghisler(Author)]

Yes, I have tried it twice with a delay of about 1 month.

[HBB]

Herbert wrote (there is no info about the test results yet):

I will run extensive memory-tests, just to be sure.

White wrote:

To me it still looks like defective memory...

Years ago, I had similar issue without BSOD. After synchronizing the dirs in my working disk with the ones in my backup disks by date/time/size, when I synchronize the same dirs by content comparison, some files were arbitrarily different. Each time a different file appeared as different. As a result, I found the reason as RAM fault. An only one byte fault at the end section of the RAM caused this. Actually operating system did not drop to blue screen.

I completely agree with White...

[primo]

Hi,

I know this is 1 year old topic but now I confirm that this issue exists in TC 8.51a (Win7 x64 SP1).

I was copying/moving large amount of files between desktop PC and NAS in both directions and from USB HD to the same desktop PC with different file sizes. During copying/moving the files, at random time, CRC check errors occurred. After stopping the operation and restarting it, the error occurs with different file, the previous file was copied/moved without any problem. But it also happened when copying one very big file (Virtualbox vdi file, size over 50 GB) that I had to restart 2 or 3 times to finish successfully. So it is very difficult to reproduce this issue.

The copy method was set to "Also use big file copy mode", but since I reset it to the recommended "Use standard copy method", the issue disappeared, no problem during the move of several thousands files (500+ GB).

I used Avast, now AVG as AV software, with the same result.
Memtest shows no problem.
I tried Teracopy, Ultracopier without any issue, but I prefer TC.

How can I help You, what additional information do You need to find the cause of the issue?


Kind Regards,
Andras Prim

[byblo]

Can you retry to copy files, and when one of them is reported with the 'crc check error', then keep it, manually calculate its checksum (using TC, crc32 or md5 or whatever) and compare with the file from your NAS? (or simply copy it again with verify enabled and until it gets copied without warning again)

If checksums are identical, will mean there is maybe a problem with this TC's function.

If different, will mean the function works well and warned you as expected, and something is wrong from your hardware and/or software.

[primo]

Hi byblo,

I forgot to mention that after one of those CRC error I made a file content compare and it showed that there is indeed a difference between the 2 files. About 1 byte in 20 GB.

I pretty sure that there is no HW failure in my desktop PC, nor in my NAS.


KR,
Andras

[Flint]

primo
Then your report does not relate to the topic-starter's bug. In his case the file was copied correctly, but TC reported it as faulty.

Concerning your problem: other users also experienced similar problems, though its source is, as of yet, a mistery. What TC does for copying files is just calling the ordinary, very standard Windows API functions, but they seem to work badly with some hardware (USB disks, NASes). It might be faulty drivers, or some buggy implementation of the server-side protocol functions on the NAS. You can try to use compatibility mode in TC for the problematic devices (that's exactly what this option was added for) — in this case TC would use other functions which seem to work better.

[primo]

Flint,

You are right, after thinking about it, my problem is not related to the original post.

Anyway, thanks a lot for your information, it is good to know that I'm not alone with this problem, and that this is not a TC issue!

Using the recommended copy method solved the problem. I'm more than happy that everything is okay!