Central and local directory mismatch for file? about php-zipstreamwriter

[cubiclesoft]

WinZIP appears to be reporting that the two CRC values are "mismatched." I guess WinZIP implemented the ZIP file format specification incorrectly.

The ZIP file format is a publicly documented format by PKWare but not technically a formal specification. That is, the format is not filed with a formal Standards body like the Internet Engineering Task Force and therefore implementations are free to misinterpret the specification as they see fit...at the risk of not being compatible with correct implementations. The ZIP file format is convoluted and traces its roots back to the mid-1980's but the current version of the specification allows for ZIP files to be generated and streamed between two hosts. In that case, the CRC32 of the file data being streamed is not necessarily known at the time that the ZIP file is generated and can be dynamically generated from a source, making advance calculations of the CRC32 impossible. By the time the CRC32 can be fully calculated, the local directory header is long gone to the other host. In such cases, the local directory header will have a CRC32 of 0 and the data will be "chunked" as per the ZIP file format specification. The actual and correct CRC32 is calculated for the Central directory, which is stored at the end of the file. The Central directory is the authority over the local directory.

This is almost certainly a problem specifically with WinZIP and not this library. The "error" message in your screenshot is letting the user know of a possible problem with the ZIP file because it is checking the two CRC32 values against each other. That is a comparison that doesn't make any sense to do for streamed ZIP files. WinZIP should be able to tell that the ZIP file is formatted as if it were streamed from a server. The CRC32 value of 0 in the local directory and a correct CRC32 in the Central directory is just one indicator of streamed content while the existence of chunked data is the more significant indicator. Windows File Explorer, 7-Zip, and many other tools appear to read streamed ZIP files without issue. So, in short, the generated ZIP file is correct and WinZIP is probably just wrong.

[jannmylj]

Hi

Thank you for your quick reply. I agree with you about illogical WinZip behaviour.

I tried to change your library to create the local directory header with pre-calculated CRC32 (and compressed size/uncompressed sized too) by modify in particular WriteLocalFileHeader method call with « forced » values in parameters. Unfortunately without success. I’m not fully satisfied by this idea, but WinZip is currently used by several our receivers.

Do you think it’s approach it’s possible or completely awkward ?

Thanks for your help looking into this (again).

Jann

[cubiclesoft]

You are probably better off filing a bug report with WinZip through their support website:

https://www.winzip.com/en/support/

The point of streaming is that data is sent as soon as it is available and that certain values are not known at the time. If someone is, for instance, generating data from a database and putting it into a ZIP file for delivery to the recipient, re-running the same SQL query again may produce different results. Precalculating the CRC-32 means you will be passing over the same data twice.

I've added an option to pass in a precalculated "crc32" option to OpenFile() to use for the local header. It will be recalculated as data is fed in for the central directory value. As to precalculating the compressed size for the local header, the only viable option for streaming data would be to not compress the data at all and would require a number of slightly hacky bypasses to make it work. IMO, all of this is ill-advised and you shouldn't cater to broken-by-design software - in this case, WinZip.