[
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.
