commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Bodewig (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COMPRESS-418) ZipArchiveEntry duplicates the size field from ZipEntry
Date Tue, 25 Jul 2017 09:49:00 GMT

    [ https://issues.apache.org/jira/browse/COMPRESS-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16099793#comment-16099793
] 

Stefan Bodewig commented on COMPRESS-418:
-----------------------------------------

You will find it returns a value different from -1 once the entry's content has been read.
This is an effect of the way size is stored in ZIP archives, depending on how the archive
has been created, size is stored after the content rather than inside the "local file header"
that sits in front of the actual data. {{ZipFile}} can use random access so is able to read
all metadata for an entry.

If you see this behavior only in achives created by Commons Compress than it is because of
the way the archive is created. If {{ZipArchiveOutputStream}} knows it is writing to a file,
it will use random access under the covers and add the size information to the metadata in
front of the entry's content. The same is true if the {{ZipArchiveEntry}} already knows its
size (compressed and uncompressed) before you start writing, but in general you don't know
the compressed size.

{{ZipArchiveEntry}} hides the {{size}} field of {{ZipEntry}} as the later can only store an
{{int}} while zip entries using ZIP64 extensions can store entries with sizes that exceed
{{Integer.MAX_VALUE}} - at least it used to be an int prior to Java7, I haven't checked it
afterwards (Java7 added rudimentary support for ZIP64).

I'm not sure how you can see the inherited size field in {{ZipEntry}} get the correct value
as {{ZipArchiveInputStream}}  never sets it.

> ZipArchiveEntry duplicates the size field from ZipEntry
> -------------------------------------------------------
>
>                 Key: COMPRESS-418
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-418
>             Project: Commons Compress
>          Issue Type: Bug
>          Components: Archivers
>    Affects Versions: 1.14
>         Environment: Java 1.8.0_131
> Apache Compress 1.14
>            Reporter: Darryl L. Pierce
>            Priority: Critical
>
> I create an archive using Apache Compress. I can read the archive fine using 7zip and
JAR (from the JDK).
> When I read the same archive using Apache Compress libraries, I get a NegativeArraySizeException
on every entry.
> When I read any other archive using Apache Compress libraries, I do not get the NegativeArraySizeException
on entries.
> When I debug this, I see that the ZipArchiveEntry object has two instance variables named
size (one it defines, which contains the correct size, and one it inherits from ZipEntry which
is -1). And it seems that, on Apache Compress-created archives, it's always returning the
inherited value and not the one defined by ZipArchiveEntry.
> In my code, I am only use instances of ZipArchiveEntry.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message