Hi Sherman,
Thanks for comments, here are some answers:
the answer to (1)-(3) is that i do whatever the
JarOutputStream/ZipOutputStream
of the current JDK does and for a reason - there was a request from
couple of customers
to make native unpack200 results binary identical to the results taken
from Java
version. The bits set in the general flags are "reserved by PKWARE" or
"Currently unused"
according to the Zip specification but ZipOutputStream sets them this
way. Same goes to the
extraction of crc/size/csize into separate header - just to be
compatible with Java
implementation.
We indeed do not support large (>4GB) files due to the limitations of
in-memory
unpacking so yes, i omitted the logic of creation of the extended Zip64 LOC
and CEN entries because there will be no case when they might be called
upon.
The only Zip64 feature is the support of the archives with >64K files - the
rest id the Java JarOutputStream compatibility tweaks.
At this moment i don't think that supporting old JDK behavior for the
jars
with >64K files is required - the older unpack200 wouldn't handle the
situation
correctly anyways. If the request for such option will emerge then
implementing
it will be a whole new task.
/Alex
On 1/15/14 8:58, Xueming Shen wrote:
Hi Alex,
(1) what's the bits are you setting into the general flags fields as
below?
header[4] = ( store ) ? SWAP_BYTES(0x0800) : 0x0808;
(2) why do you want to use extra data descriptor to set crc/size/csize?
while I understand that Jar/ZipOutputStream does that, but that is
because
they don't have the choice given the nature of "stream", which means they
don't know the csize and crc value until all bits get
compressed/crc-ed. In
case of unpack, all bits should have already be compressed and the crc
value
has been calculated, I don't see any compelling reason we need to sue the
extra data descriptor here.
(3) to add the "cafe" jar magic is interesting. that is really an old
implementation
details of "jar on solaris". any request to add this one into the
unpack tool?
(4) I dont think the changeset is tryin to support ZIP64 extra fields
tag in
LOC and CEN tables (I kinda understand why, given the unpack does all
"unpacking" work in memory, it is practically unrealistic to have a >4G
memory to hold all > 4G data). It appears most of the changes other
than the
zip64 end table is really not related to "support the new zip64 format"
(5) flag "jdk.util.zip.inhibitZip64" is introduced in jdk8 to support
a "old"
behavior for > 64K total entries. You guys might want to consider if
it is
also worth considering to have this flag supported in unpack200.
-Sherman
On 1/14/14 10:04 AM, Alexander Zuev wrote:
Please review my fix for
JDK-8029646: [pack200] should support the new zip64 format.
The fix can be found at
http://cr.openjdk.java.net/~kizune/8029646/webrev.00/
Bug description is: https://bugs.openjdk.java.net/browse/JDK-8029646
/Alex
