[
https://issues.apache.org/jira/browse/COMPRESS-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903035#comment-16903035
]
Stefan Bodewig commented on COMPRESS-489:
-----------------------------------------
{{ZipFile}} does read the central directory and provides all extra data that is
part of the central directory. What you are asking for is the "may return
incomplete extra field data" part of
[http://commons.apache.org/proper/commons-compress/zip.html#ZipArchiveInputStream_vs_ZipFile]
.
{{ZipArchiveInputStream}} reads the archive from the start and hands out
{{ZipArchiveEntry}} instances as soon as it has parsed the local file header.
Technically it would be possible to add the extra fields of the central
directory in retrospect once the stream has reached the central directory. Most
of our consumers will have discarded the {{ZipArchiveEntry}} instances by then
already, though. This is why we've decided to not even try that - keep in mind
this is only one of several of {{ZipArchiveInputStream}}'s flaws - but rater
tell people to use {{ZipFile}} whenever possible instead.
Even {{ZipFile}} does not even try to parse the archive extra data as its
contents seem to only be related to the PKWARE archive encryption feature that
we are not allowed to implement - see section "Incorporating PKWARE Proprietary
Technology into Your Product" in the current APPNOTE.txt.
> Reading Central File Header and Archive extra data record, with out Skipping
> ----------------------------------------------------------------------------
>
> Key: COMPRESS-489
> URL: https://issues.apache.org/jira/browse/COMPRESS-489
> Project: Commons Compress
> Issue Type: Improvement
> Reporter: Anvesh Mora
> Priority: Minor
> Attachments: image-2019-06-10-17-02-33-972.png
>
>
> - Some Zip files store extra data in CFH and AED. Right now it seems that we
> are skipping the meta data instead of making it available to consumer and
> choose to use it or not.
> - It might sound small change but right now this kind of flexibility is not
> allowed with inheritance, due to lot of private and package access specifiers
> ( NOT open for extension)
> - If extension is not something we are looking, providing a method which
> allows to store CFH and AED data based on a flag, should make it work.
>
> I had similar requirement in my current development and I had to re-write the
> component and use below code-snippet in
> ZipArchieveInputStream#getNextZipEntry method:
> !image-2019-06-10-17-02-33-972.png!
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
