[
https://issues.apache.org/jira/browse/COMPRESS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Power updated COMPRESS-215:
---------------------------------
Attachment: COMPRESS-215.patch
This proposed patch works by searching for the End Of Central Directory record
first which should always be found close to the end of the file. From here it
uses the fact that the ZIP64 EOCDL will be a fixed size and be immediately in
front of the EOCD in the file to find it. If it is not there it is not ZIP64
and there is no reading further back to look for it.
This performance improvement hinges on the knowledge that the ZIP64 EOCDL is
consistently positioned relative to the EOCD. If this is not the case in some
implementations please let me know :)
> ZipFile reads up to 64KiB in a sequence of one byte reads
> ---------------------------------------------------------
>
> Key: COMPRESS-215
> URL: https://issues.apache.org/jira/browse/COMPRESS-215
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
> Affects Versions: 1.4.1
> Environment: JDK 1.7 64-bit, Windows 7
> Reporter: Robin Power
> Priority: Minor
> Attachments: COMPRESS-215.patch
>
>
> This relates to a performance improvement.
> When ZipFile is parsing a file it searches for the ZIP64 End Of Central
> Directory Locator as a first step to determining if the file is ZIP64 or
> regular 32 bit. It searches in reverse for the ZIP64 EOCDL signature from the
> end of the file reading one byte at a time, potentially up to about 64KiB.
> This can be an expensive operation, especially if it is not a ZIP64 file, as
> it will make over 64000 file reads to determine that the file is not ZIP64.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
