You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Stefan Bodewig (JIRA)" <ji...@apache.org> on 2010/03/19 16:11:29 UTC

[jira] Resolved: (COMPRESS-103) allow data descriptors to follow STORED entries in ZIP archives being read

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

Stefan Bodewig resolved COMPRESS-103.
-------------------------------------

       Resolution: Fixed
    Fix Version/s: 1.1

fixed with svn revision 925257, I'll add some documentation shortly.

Note that the heuristics used are not safe.  For example if the stored entry is a ZIP archive
itself (think JAR inside a WAR) the stream would now happily extract the inner archive's
contents and consider the outer archive finished as soon as the central directory
of the inner archive has been encountered.


> allow data descriptors to follow STORED entries in ZIP archives being read
> --------------------------------------------------------------------------
>
>                 Key: COMPRESS-103
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-103
>             Project: Commons Compress
>          Issue Type: New Feature
>    Affects Versions: 1.0
>            Reporter: Stefan Bodewig
>            Priority: Minor
>             Fix For: 1.1
>
>
> the document named "Word XPS.xps" found under http://www.wssdemo.com/XPS/Forms/AllItems.aspx contains at least one STORED entry that uses a data descriptor after the entries' data to hold size and CRC information.
> The ZipFile class uses information from the central directory and thus knows the size of the entry and can deal with the archive.  ZipArchiveInputStream currently can't.
> One solution would be to read the entry until we hit the signature of a data descriptor, local file header or the start of the central directory.  If we hit another LFH or the CD then the data descriptor didn't use the signature (see COMPRESS-101 ) and the last 12 bytes read have already been the data descriptor.  This will certainly not be very efficient.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.