You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stefan Bodewig <bo...@apache.org> on 2011/08/01 16:49:45 UTC
[compress] Some ZIP64 Interop Results
Hi,
I've checked current trunk's ZipArchiveInputStream and
ZipArchiveOutputStream implementations against InfoZIP's zip (Cygwin in
this case), 7ZIP, windows Compressed Folders and Oracle's final Java7
JDK's jar command - all on Windows 7.
For InputStream I've created an archive with a single compressed entry
of 5 billion zeros with each of the tools as well as one archive with
100k files of size 0bytes each.
Windows Compressed Folders uses a compression method that we don't
support (Deflate64, method number 9) and it seems to be a good idea as
the resulting archive is 168kB rather than the 4.6MB created by all
other tools. Anyway, this archive can not be used in tests.
All other archives are read correctly by ZipArchiveInputStream, there is
a problem with reading the size of the big entry inside the archive
created by jar, but this clearly is a bug in Java7 and I'm going to
report it against OpenJDK[1] (and may have a workaround, need to think
about it a bit longer).
If you remove all @Ignores from ZIP64SupportTest and comment the two
f.delete[OnExit] lines you end up with 16 archives testing a lot of
ZIP64 features, all of them created by ZipArchiveOutputStream.
InfoZIP and Windows Compressed Folders consider all 16 of them valid,
7ZIP doesn't like the one that writes 100k files to a non-seekable
stream and jar dies on the three archives that write big deflated
entries. I'll investigate this further but suspect that there is
another bug in jar (while I trust 7ZIP at this point).
As far as performance goes trunk is on par with InfoZIP's ZIP and jar,
likely because all three of them use ZLIB under the covers. 7ZIP is
significantly faster but seems to choose a lower compression level,
Windows Compressed Folders is fast on some and quick on other archives.
Stefan
[1] Once I manage to set finalize the account creation process at the
bug database, that is. Do they really think I'd give them my business
phone number and street address in order to report a bug?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] Some ZIP64 Interop Results
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-11, Emmanuel Bourg wrote:
> Le 01/08/2011 16:49, Stefan Bodewig a écrit :
>> All other archives are read correctly by ZipArchiveInputStream, there is
>> a problem with reading the size of the big entry inside the archive
>> created by jar, but this clearly is a bug in Java7 and I'm going to
>> report it against OpenJDK[1] (and may have a workaround, need to think
>> about it a bit longer).
> Just stumbled on this:
> http://blogs.oracle.com/xuemingshen/entry/is_zipinput_outputstream_handling_of
> Is this a follow up of the issue you spotted?
Looks like it, yes. I opened
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7073588> which was
available until two days ago and no longer is - and I was never notified
of any status change.
The content of the blog article and PKWARE's response is quite differet
from what the InfoZIP implementation does and what the comments inside
the source tree of InfoZIP call "industry interpretation". I have
reported this as well.
I don't really care much as I know our ZIPs are considered valid by all
ZIP imeplementations I have checked (didn't check PKZIP, though) except
for jar that I'm going to re-access. And our code consumes archives
created by all those implementations including jar.
Maybe I should write a blog post of my own 8-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] Some ZIP64 Interop Results
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 01/08/2011 16:49, Stefan Bodewig a écrit :
> All other archives are read correctly by ZipArchiveInputStream, there is
> a problem with reading the size of the big entry inside the archive
> created by jar, but this clearly is a bug in Java7 and I'm going to
> report it against OpenJDK[1] (and may have a workaround, need to think
> about it a bit longer).
Just stumbled on this:
http://blogs.oracle.com/xuemingshen/entry/is_zipinput_outputstream_handling_of
Is this a follow up of the issue you spotted?
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] Some ZIP64 Interop Results
Posted by Jörg Schaible <jo...@gmx.de>.
Stefan Bodewig wrote:
> On 2011-08-01, Jörg Schaible wrote:
>
>> Stefan Bodewig wrote:
>
>> [snip]
>
>>> [1] Once I manage to set finalize the account creation process at the
>>> bug database, that is. Do they really think I'd give them my business
>>> phone number and street address in order to report a bug?
>
>> I always do:
>> +00042-4200420042
>> 42/0 Lunar City, Moon
>
> The phone number would have been in the wrong format (as was "you must
> be kidding").
>
> Actually I thought I'd have to create an Oracle SSO account in order to
> create a new bug report but it turned out I was wrong - at least the
> form wasn't smart enough to fill in my data and I had to enter it again.
>
> The bug reporting process is pretty painful compared to other open
> source communities IMHO. I don't have a ticket number now, I may
> receive one by email, if and once they had time to review my report -
> oh, and if the bug hinders progress of my project I might consider
> purchasing support 8-)
>
> I better stop before I get even further off topic.
This reminds me to a bug report for Adobe Reader. I could have chosen
directly /dev/nul.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] Some ZIP64 Interop Results
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-01, Jörg Schaible wrote:
> Stefan Bodewig wrote:
> [snip]
>> [1] Once I manage to set finalize the account creation process at the
>> bug database, that is. Do they really think I'd give them my business
>> phone number and street address in order to report a bug?
> I always do:
> +00042-4200420042
> 42/0 Lunar City, Moon
The phone number would have been in the wrong format (as was "you must
be kidding").
Actually I thought I'd have to create an Oracle SSO account in order to
create a new bug report but it turned out I was wrong - at least the
form wasn't smart enough to fill in my data and I had to enter it again.
The bug reporting process is pretty painful compared to other open
source communities IMHO. I don't have a ticket number now, I may
receive one by email, if and once they had time to review my report -
oh, and if the bug hinders progress of my project I might consider
purchasing support 8-)
I better stop before I get even further off topic.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] Some ZIP64 Interop Results
Posted by Jörg Schaible <jo...@gmx.de>.
Stefan Bodewig wrote:
[snip]
> [1] Once I manage to set finalize the account creation process at the
> bug database, that is. Do they really think I'd give them my business
> phone number and street address in order to report a bug?
I always do:
+00042-4200420042
42/0 Lunar City, Moon
SCNR :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org