Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
Description
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.