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
