More files than entryCount

My apologies if this is addressed elsewhere. I couldn’t find it in the README or Issues.

I have a zip file with ~70K files, but the file catalog says it has only 14,202. On my Mac: unzip -Zh file.zip yields “Zip file size: 139476498 bytes, number of entries: 14202” unzip -l file.zip yields “557051138 … 79738 files”

I’m not sure where the discrepancy comes from, but if I unzip the file using unzip on the command line, or double click it in Finder, all ~70K files unzip.

Using yauzl, it only unzips the first 14202 files and then ends/closes. I tried with my own implementation and also using examples/unzip.js in the repo.

Is there some way to configure yauzl to unzip all the files in the zip, regardless of the reported number of entries?

[overlookmotel]

@RickDT Please see https://github.com/thejoshwolfe/yauzl/issues/69#issuecomment-383424896

[thejoshwolfe]

After much yak shaving (rewriting my zip file analysis tool to be more memory conservative (and developing the programming language it is written in)), I’ve figured out what the issue is with this zipfile. It’s pretty much the same problem as issue #69.

When the Mac Archive Utility needs to write the 16-bit entry count in the end of central directory record, it doesn’t check for overflow, and simply writes the lower 16 bits of the entry count. In the OP here, the real entry count was 79738 or 0x1377a, and Archive Utility wrote 14202 or 0x377a in the zip file metadata. In the zipfile you linked me, the numbers were 0x14595 and 0x4595.

This means that the metadata is an outright lie about the number of entries in the zipfile. This is absolutely a bug in Archive Utility, and it’s a nasty one too. The correct behavior would have been to use ZIP64 format, but Archive Utility has no idea what that is.

There may or may not be any way to correctly and reliably recover from this corruption. I’m still thinking about it.