"Invalid size or check sum of file" error in zip file

[bcoldtimer]

I created an empty zip file using Windows Explorer (Win 7 Pro). Then I compared it to a folder using BeyondCompare. I copied some files and folders into the zip file. Then I started to get "Invalid size or check sum of file" errors after copying some files. The comparison rule was set to Binary comparison. Most of the files compared OK (binary identical) when first copied, but many of them later became grayed out and showed the error "Invalid size or check sum of file". What's happening? I just updated to the latest version 3.3.8 and that doesn't seem to help. Please help. Thanks!

[Chris]

It looks like this is a bug relating to BC performing binary comparisons of zip files. If you switch to CRC comparison when using zip files, it should avoid the issue.

I repeated this bug and added it to our bug list, we'll work on a fix for an upcoming release of BC.

[bcoldtimer]

Thanks! Switching to CRC did seem to work better now. Now in the CRC mode, what does the "=" sign with small "0" and "1"s next to it mean? Binary identical or just same CRC? Thanks!

[bcoldtimer]

Another related issue: when I double clicked on a pair of files (now not grayed out since switched to CRC) to compare them in the default text viewer, I got the same error. I turned off CRC comparison but still got the same error.

[Chris]

The 01 next to the equal means CRC or binary equal. An equal with 01 next to it means rules-based identical.

[Chris]

Does the error still show up if you close BC, then open the session with CRC set as the comparison type right from the beginning?

[bcoldtimer]

Yes. I tried just closing the tab then re-opening in a new tab and I also tried quitting BC then restarting BC, both with CRC comparison set from the beginning. In both cases when I tried double clicking a pair of files to compare in the text comparator it gave the same error message "Invalid size or check sum of file".

[Aaron]

What type of file is the file you are trying to open? Is it a plain .txt, or is it a .doc or other file type?

If you copy the each file to your desktop individually, then open only one at a time in the Text Compare or Text Edit, does it throw an error for one or both of them?

[bcoldtimer]

It's plain txt file. I tried copying from withing the zip file and pasting to a folder using Windows Explorer and got a Windows error 0x80004005: Unspecified error. Now I worry the zip file is corrupted.

[Aaron]

Hello,

That does sound like a corrupted zip if Windows Explorer cannot extract the files. I tested this out on my own machine and it seemed to work when I create an empty Zip file and then set it as a base folder and copy files into it. Are you able to reproduce this using a similar set of steps and sample files? Or was this a random, one time corruption?

[bcoldtimer]

I will test the steps again later and report back.

When you did your test, did you set the comparison rule to binary comparison?

[Aaron]

Ah, I had Binary compare enabled, but I did not have a sufficiently large test case. Chris was able to repeat some issue during the copy procedure following similar steps and a large folder that is copied. I have not hit the exact set of errors you are hitting, but I'm definitely repeating an issue of some sort. We'll open a tracker entry and get this investigated.

[sully9]

Any news on a fix for this bug?

There are very few things that I *don't* like about BC. Sadly, this is one of them and I bump into it regularly. since BC is always open on my system and gets used about 2 dozen times a day.

One of the greatest features (for me) about BC is that it can "do it's thing" on ZIP files.

For reasons I won't go into, I have regular need to review and sync files from a local folder into a local ZIP file. I don't think I'm stressing any limits: 16MB uncompressed, a sub folder tree with 6 folders, 64 files some binary, some text, some source code) Over the past few years I have grown to dread this process inside of BC.

Three observations:
1) I have not rigorously tested this, but the likelihood of the error seems to go up if I try to sync multiple files into the zip. If I do only one or two files at a time, it seems happen a bit less often.
2) Even so, sometimes trying to sync a single file throws the error. If I refresh and try again, it works successfully.
3) Repeating this retry process described in #2 of hammering each updated file into the ZIP, I'm sometimes left with a thoroughly corrupt ZIP - confirmed by running a test in 7-Zip / Winzip / PkZip. Other times, the ZIP survives intact, again confirmed by running a test.

Here's hoping the bug is approaching the top of the hit list.

[Aaron]

Hello,

Thanks for the follow-up. This is still an open tracker entry. We have reproduced a bug, we just haven't been able to get a fix just yet.

[edwardhague]

I am getting this error in 4.0.7, binary file comparisons in a Windows 7 zipped 'folder'. Tech support can contact me edward at connect-ex.com