RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files [v12]

[Eirik Bjørsnøs]

On Tue, 16 Jan 2024 13:54:06 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Eirik Bjørsnøs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove trailing whitespace
>>  - Remove trailing whitespace
>
> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 664:
> 
>> 662: 
>> 663:         // The LOC's 'compressed size' and 'uncompressed size' must both be marked for Zip64
>> 664:         if (csize != ZIP64_MAGICVAL || size != ZIP64_MAGICVAL) {
> 
> The spec for this says different. It says:
> 
>>
>> 4.4.4 general purpose bit flag:
>> ...
>>    Bit 3: If this bit is set, the fields crc-32, compressed size and uncompressed size are set to zero in the local header.  The correct values are put in the data descriptor immediately following the compressed data.  
> 
> So it expects the value zero for the compressed/uncompressed sizes in the LOC when the data descriptor bit is set.

The spec isn't terribly helpful in spelling out what should happen in the case where an entry combines the uses of  data descriptors (mandating that CRC, size and compressed size must be zero) with Zip64 (mandating that size and compressed size must be 0xFFFFFFFF)

My interpretation (based in the InfoZIP implementation) is that in such cases, CRC should be zero, while size and compressed size should be 0xFFFFFFFF, with their counterparts in the Zip64 extra field should set to zero.

Does this make sense?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1453526069