commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis Lundberg (JIRA)" <>
Subject [jira] Moved: (COMPRESS-47) Make ZiparchiveInputStream support as much of the zip package as possible
Date Mon, 23 Mar 2009 22:19:56 GMT


Dennis Lundberg moved SANDBOX-293 to COMPRESS-47:

    Component/s:     (was: Compress)
            Key: COMPRESS-47  (was: SANDBOX-293)
        Project: Commons Compress  (was: Commons Sandbox)

> Make ZiparchiveInputStream support as much of the zip package as possible
> -------------------------------------------------------------------------
>                 Key: COMPRESS-47
>                 URL:
>             Project: Commons Compress
>          Issue Type: Improvement
>            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 - 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.

View raw message