[
https://issues.apache.org/jira/browse/SANDBOX-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683751#action_12683751
]
Stefan Bodewig commented on SANDBOX-293:
----------------------------------------
ZipFile uses RandomAccessFile so it can scan for the CN without reading the
whole file (it just reads the file backwards from the disk).
For the factory I'd assume we'd always use ZipArchiveInputStream but advise
people to use ZipFile directly when they really want to read a zip archive. I
wouldn't tie ZipFile into the factory at all.
> Make ZiparchiveInputStream support as much of the zip package as possible
> -------------------------------------------------------------------------
>
> Key: SANDBOX-293
> URL: https://issues.apache.org/jira/browse/SANDBOX-293
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Compress
> Reporter: Stefan Bodewig
>
> Copying something I sent to the dev list:
> > Generally speaking the InputStream metaphor doesn't work for ZIP
> > archives.
> > A ZIP archive contains what is called "central directory" at the end
> > of the archive. This is the only authoritative source telling you
> > what is inside that archive.
> > Before the central directory there are the actualy contents (among
> > other things). For each entry you get a local file header describing
> > the entry (duplicating information from the central directory) and the
> > actual contents. The central directory contains a pointer to the
> > local file data.
> > java.util.ZipInputStream reads the stream in sequence and creates
> > ZipEntries as it finds local file information.
> > ZipFile (our, not the one in java.util.zip - I don't know what the
> > later does) reads the archve from the back and parses the central
> > directory to see what is inside the archive.
> > It is not uncommon for archiver to "update" existing archives by
> > adding new local file data at the end and rewrite the central
> > directory without removing the old local file data. In such a case
> > java.util.ZipInputStream will find entries that shouldn't be there or
> > worse old data for updated entries.
> Having said that, the only alternative for people who really only have a
> stream and
> not a file is java.util.ZipInputStream and we cn at least do better than that.
> We need a ZipArchiveInputStream that shares the broken "if there is local
> file data
> there is a ZipArchiveEntry" logic with ZipInputStream but uses the data
> parsing
> code of ZipFile to provide all the benefits of encoding support, access to
> external
> attributes and parsed extra fields.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
