commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Grobmeier (JIRA)" <j...@apache.org>
Subject [jira] Updated: (COMPRESS-47) Make ZiparchiveInputStream support as much of the zip package as possible
Date Thu, 26 Mar 2009 05:37:51 GMT

     [ https://issues.apache.org/jira/browse/COMPRESS-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Christian Grobmeier updated COMPRESS-47:
----------------------------------------

    Fix Version/s: 1.1

planned for version 1.1

> Make ZiparchiveInputStream support as much of the zip package as possible
> -------------------------------------------------------------------------
>
>                 Key: COMPRESS-47
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-47
>             Project: Commons Compress
>          Issue Type: Improvement
>            Reporter: Stefan Bodewig
>             Fix For: 1.1
>
>
> 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