[
https://issues.apache.org/jira/browse/COMPRESS-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16623932#comment-16623932
]
Stefan Bodewig commented on COMPRESS-465:
-----------------------------------------
Yes, the first entry of the archive is a itself ZIP and says it is using the
data descriptor. This is something that {{ZipArchiveInputStream}} is simply not
able to handle and the documentation more or less says so much. See
http://commons.apache.org/proper/commons-compress/zip.html#ZipArchiveInputStream_vs_ZipFile
{quote}for STORED entries ZipArchiveInputStream can try to read ahead until it
finds the next entry, but this approach is not safe{quote}
I'll make the documentation a bit more explicit, but there isn't anything we
can do about it in general. You should be using {{ZipFile}}, really.
In the specific case of your archive there might even be a theoretical way as
the archive violates the ZIP spec and includes a "compressed size" inside of
the local file header even though the spec says it must be set to 0, but I
haven't checked whether this size is correct. I don't think it would be good to
trust a value that the spec explicitly forbids to be present and wouldn't want
to base any heuristics on it.
> Unexpected record signature: 0X6F4A2D4E
> ---------------------------------------
>
> Key: COMPRESS-465
> URL: https://issues.apache.org/jira/browse/COMPRESS-465
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.18
> Reporter: Luis Filipe Nassif
> Priority: Major
> Attachments: test.zip
>
>
> Hi,
> Commons compress is not recognizing all entries from zip files downloaded
> from mega.nz cloud, when you choose to download several files as a zip
> archive. Others archivers like 7zip and Windows Explorer are able to read all
> zip content. Example attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
