Never-ending comparison?? (BC Beta 2.1 Build 212)

[zjboy]

Howdy,
CAVEAT: I'm starting pretty much without a clue using BC, so perhaps I'm the error that needs to be corrected ...

I'm trying to use BC Beta 2.1 Build 212 to verify that a 702MB .rar file on my hard drive has been successully copied to a CD. So I set up a directory compare between the CD drive directory and the hard drive directory containing the .rar file. I then changed the comparison rules to check by size and CRC.

BC has been reading the CD drive for about the last 10 or 15 minutes! ?? (By comparison, when I wrote the CD using Nero the data verification only took at most 5 minutes)

But what is more annoying to me is that the only way I seem to be able to get BC to stop is by ending BC abnormally. I tried using what appeared to be a "STOP" button on the BC toolbar. Unfortunately, it looks like whatever BC is doing at the moment it is not seeing any interaction with the BC user interface.

Two questions.
First, is BC supposed to work this way? (Seems unlikely)
Second, is there a better way to do the comparison/verification I'm trying to do with BC?

[zjboy]

Ok, I think I figured it out.

The reason I was seeing the BC user interface go "unresponsive" for minutes was because I was displaying the "CRC" column in the BC file list. While BC is calulating the CRC to display it doesn't seem to accept user input. If you don't display the CRC then the behavior is OK.

Since it takes about 130 seconds or so to read my 702MB CD, BC goes unresponsive for that period of time whenever I would do a comparison. If the CRC is not displayed though the BC window does not "block". Interesting.

Even more interesting was when I had BC perform a binary file comparison while the CRC was displayed in the file list. Performing a quick refresh after placing a new CD in the drive would take twice as long ... around 260 seconds. My guess is that after the CD was inserted and F5 was pressed, BC would first calculate the CRC of the file on the CD which took around 130 seconds. Then BC would read the entired CD again to perform the binary compare taking another 130 seconds. Total 260 seconds.

What prompted me to post here in the first place is because BC when unresponsive on my for around 2880 seconds. This happened when I add CRC to file list columns. It happened because I not only had a 702MB file in the CD drive, but also around 23 of them on the hard drive. It took 48 minutes or for BC to calculate the CRC's for all those files. And while it was doing that the BC user interface was not responsive.

[Craig]

Your guesses are exactly right. The CRCs are calculated in the foreground if the CRC column is visible and it will hang BC pretty hard if the files are large. We'll fix that in a future release, but it'll be a while. Unless the CRCs are already calculated (eg, zip or snapshot files), or the files are small I wouldn't suggest displaying the CRC column.

For disk verifications we recommend using binary comparisons instead of CRC ones. Binary comparisons use less CPU time, so they'll usually be faster. They can also stop as soon as the first difference is found, unlike CRC comparisons which have to read both files completely before comparing them.

If the CRC column is visible and you're doing a binary comparison BC will read all of the files twice. If you do a CRC comparison instead the CRCs will be cached so it will only read it once. I seriously doubt that we'll integrate the binary comparisons and CRC calculations in order to only read the disk once. That would complicate the logic for both, and usually you'll only want to use one or the other.

So, recommendation-wise:
- Use binary comparisons when comparing file contents.
- Use CRC comparisons when comparing against snapshots or zip files. Both store the CRCs explicitly, so even if you're comparing against a regular disk it will only have to read one side.