ZIP file incomplete contents

[chaperoni]

Is there a file size limit for comparing ZIP files as folders correctly? Or maybe a file count limit? I'm comparing zips from a game around 1.8gb in size with 68251 files and within beyond compare their contents are significantly incomplete (>75%). Even unpacking all the data and rezipping them myself causes this issue.

Although the archives open properly in other applications, using a zip-repair utility reveals some junk files that might be causing a problem. Is it possible to make beyond compare skip over junk instead of stopping completely?

[Chris]

This is described in our Max File Size page.

BC 3.1 and newer support Zip64 for files over 4 GB in size. Versions prior to 3.1 are limited to 65,535 files, with no file larger than 2 GB, and a maximum Zip file size of 2 GB.

Make sure you're running the newest version 3 release, version 3.3.13 for maximum compatibility. If that still doesn't work, it might help to try an evaluation version of Beyond Compare 4 to see if it handles your files better.

[chaperoni]

This is described in our Max File Size page.

BC 3.1 and newer support Zip64 for files over 4 GB in size. Versions prior to 3.1 are limited to 65,535 files, with no file larger than 2 GB, and a maximum Zip file size of 2 GB.

Make sure you're running the newest version 3 release, version 3.3.13 for maximum compatibility. If that still doesn't work, it might help to try an evaluation version of Beyond Compare 4 to see if it handles your files better.

Hi Chris,
Thanks for the info. I am indeed running the latest version 3 release and the issue is present in version 4. I have found a workaround which seems to fix the problem. Repairing the archives and deleting the 2 or 3 junk files that appear causes the missing files to appear in beyond compare. I'm working to get the developers creating these archives to figure out the issue on their end, but in the meantime it seems like beyond compare stops scanning the archive upon reaching these junk files/data. Is there a way to change this behavior? Of course, it's not a critical issue and I'm not demanding you account for mistakes of other developers, it would just save me time as processing these large archives takes awhile.

[Aaron]

Hello,

If your developers can create one of these archives with a dozen files and a couple of these junk files, can you reproduce the issue with a much smaller zip? If so, would you be able to email the sample zip into [email protected]? Please include a link back to this forum thread in the email for our reference.

We don't intentionally "stop" loading mid-way. Usually, either the zip can be opened or it's corrupt, mirroring behavior seen in other archive software.