commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Bodewig (JIRA)" <j...@apache.org>
Subject [jira] Created: (SANDBOX-293) Make ZiparchiveInputStream support as much of the zip package as possible
Date Thu, 26 Feb 2009 13:35:01 GMT
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.


Mime
View raw message