CRC or Binary ? which is faster

[M7md]

We have done file migration , and oddly many files was copied as corrupted to the target folder.
I am using beyond Compare with CRC filter to find the corrupted files and overriding them from the source.

However, we have millions of files to compare , and CRC is taking very long time to read files.

• Is there any faster approach to find corrupted files ?
• Is Binary comparison faster ?
• Does the licensed version give better performance or does the free version has limitation when it comes to scanning huge number of files?
• will increasing the server resources speed up the Scanning (RAM, CPU) ?

[RodolfoGiovanninetti]

One quick and dirty idea is this.
If You are working only on one system, it uses the network to transfer data from the remote one, so it is slow.
You might want to work on one system, scan the local folder and save snap-shot with crc data.
Then You copy the snap-shot.bcss file to the other system, and compare the snap-shot with the copy of the folder.
In this way most of the job is done locally.
You have to test this idea to check if it suits Your needs.

Regards

Rodolfo Giovanninetti

[devin]

If your source is known to be correct, why not to rsync to the target?

[Aaron]

If the size is different, using Size criteria would be much faster than a content scan. If the files have equal sizes but can still be corrupt, then a Binary scan would be faster. CRC requires scanning the entire file to generate the CRC code, while a Binary scan can stop as soon as a difference is hit. A content scan does require download the file from a remote server in most cases, however, so this can take a significantly longer time to both (temporary) download and scan.

The trial has identical performance and feature set to the registered version, where registering removes the days-of-use trial time limit. Any testing can be done with the trial before purchase is necessary.

Increasing server resources might help if those resources are the bottleneck for downloading the temp files, but it's more likely the connection speed that is the slowest factor.