[jira] [Commented] (COMPRESS-623) make ZipFile's getRawInputStream usable when local headers are not read

["Gary D. Gregory (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/COMPRESS-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600073#comment-17600073 ] 

Gary D. Gregory commented on COMPRESS-623:
------------------------------------------

The PR seems OK to me. Thoughts from anyone else?

> make ZipFile's getRawInputStream usable when local headers are not read
> -----------------------------------------------------------------------
>
>                 Key: COMPRESS-623
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-623
>             Project: Commons Compress
>          Issue Type: Improvement
>            Reporter: Dawid Weiss
>            Priority: Minor
>          Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> I have a somewhat odd use case with gigabytes of ZIP files, each with thousands of documents (on comparatively slow, network drives). We need to restructure these ZIPs without the need to recompress files.
> The above turns out to work almost perfectly with raw-data copying ZipFile offers but empirical tests showed a major slowdown in the initial opening of zip files, linked to multiple reads/seeks for local file headers. If an option is passed to ignore those headers, raw streams are inaccessible.
> I've taken a look at the code and the code in getRawInputStream could basically do the same thing that getInputStream does - lazily load the missing offset via getDataOffset(ZipEntry). In fact, getInputStream could just call getRawInputStream directly, which avoids some code duplication. 
> I see speedups for opening and copying random raw streams in the order of 3-4x and all the current tests pass. I filed a PR at github - happy to discuss it there.
> [https://github.com/apache/commons-compress/pull/306]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)