JDK-8173072: zipfs fails to handle incorrect info-zip "extended timestamp extra field"

[Xueming Shen]

On 1/19/17, 11:44 PM, Alan Bateman wrote:
>
>
> On 19/01/2017 23:35, Xueming Shen wrote:
>> Thanks Claes!
>>
>> webrev has been updated accordingly
>>
>> http://cr.openjdk.java.net/~sherman/8173072/webrev
>>
> The changes looks okay although I'd to understand more as to why tools 
> might be generating the extra fields in this way.

I'm reading info-zip ZIP file spec again.  it turned out this might be a 
legitimate extra fields.
The spec suggests the "flags" in BOTH headers indicate what are in the 
"local" extra field. So
The flags in central header also indicates the local entry, not the cen 
entry at all, confirmed
with info zip tool.

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

          The lower three bits of Flags in both headers indicate which time-
          stamps are present in the LOCAL extra field:

                 bit 0           if set, modification time is present
                 bit 1           if set, access time is present
                 bit 2           if set, creation time is present
                 bits 3-7        reserved for additional timestamps; not set

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

It means we need to fix the ZipOutputStream to output the correct cen 
entry flags, if there
are more extra timestamps. (jar does not create them)

>
> Also is the "zipinfo-time" property needed now?

Yes, that property basically serves the purpose of helping performance. 
If you are interested
at mtime ony and care about performance. The flag will help not go up to 
read the loc entry,
even there are a/ctime entries there.

-Sherman