[
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)
