CRC and binary comparisons yielding different results

[Sodium]

Hello,

For two particular pairs of files, BC 3.2.4 (build 13298) reports that the files differ when I compare their contents using the CRC method and that they match when I compare their contents using the binary method.

One side of each pair of files resides inside a split RAR file and the other side resides on my file system. I've tried this on Windows 7 and Windows Server 2008 R2.

Obviously the CRC values cannot differ if the files are identical, as indicated by the results of the binary compare, so I'm wondering if anyone has an idea of what might be going on here.

Regardless of whether I use the CRC or binary method, all the other thousands of files in this particular RAR file are reported by BC to be identical to the corresponding extracted files on the file system. The problem occurs consistently with just the two particular pairs of files.

Unfortunately I cannot provide the files--which belong to a client of mine--for testing. Let me know if there is any other information I can provide.

Thank you.

[Aaron]

Hello,

Thanks for the information. For the RAR side, are you expanding and treating the rar as a folder, scanning the files inside against an extracted copy?

If so, can you try extracting the rar to a temporary location, and comparing the temp location to the other copy (both non-archive), as CRC and Binary?

You can also enable the CRC column in the Folder Compare (right click a column header and enable additional columns). My first hunch is that archive types often store CRC information with the archive, and that information in this archive is incorrect. The CRC scan would look at and use this stored info, but a binary scan would extract and compare the file.

Also, all BC3.x updates are free for 3.x users. If you want, you can update to the latest release (3.3.10) from our website or using the Help menu -> Check for Updates.

[Zoë]

RAR archives store each file's CRC as part of the metadata longside the name, last modified time, and size. BC trusts those values to be accurate, so it doesn't re-calculate it. In this case it appears that part is corrupted, but the file data itself is correct, so when BC extracts it as part of the binary compare it is correctly showing up as a match.

[Sodium]

Thank you for the reply. I had selected the RAR itself as one side of the comparison. The other side of the comparison was the exploded contents of the RAR.

[Sodium]

Thank you for the explanation. I did not know that BC uses CRCs from archives. That makes sense. Good to know.