[
https://issues.apache.org/jira/browse/SANDBOX-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683343#action_12683343
]
Christian Grobmeier commented on SANDBOX-293:
---------------------------------------------
Do you say that our ZipFile reads the whole archive into memory to get the info
from the CN (which is located at the end of the stream) BEFORE returning the
ZipArchiveEntrys?
If so, doesn't that cause problems with big archives and low memory machines?
Since the ArchiverFactories work with Streams as params (and not with files),
how could we differ between what the user needs? First guess is to simply add a
new key to the factories. For example: getArchiver("zip") and
getArchiver("zip-sequence")
> 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.
