[
https://issues.apache.org/jira/browse/COMPRESS-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16098289#comment-16098289
]
Darryl L. Pierce commented on COMPRESS-418:
-------------------------------------------
Yes, using ZipFile instead of ZipArchiveinputStream works as expected.
Though I do think it's still a bug that ZAIS does not work as desired; i.e.,
using the Java debugger I do see the two instance variables and, though one
holds the entry's size, the getSize() method always returns -1 on archives
created by the Compress libraries.
> 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)
