Github user kvr000 commented on the issue:
https://github.com/apache/commons-compress/pull/24
@bodewig : Thanks for suggestions. There are definitely some pros with the
approach, especially if it reaches Zip RFC :-)
On the other hand, I don't think it could be made compl
GitHub user kvr000 opened a pull request:
https://github.com/apache/commons-compress/pull/24
COMPRESS-391: Allow alignment on zip content
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/kvr000/commons-compress
feature/COMPRESS
GitHub user kvr000 opened a pull request:
https://github.com/apache/commons-compress/pull/22
COMPRESS-390: Expose stream offsets and size
Pull request for https://issues.apache.org/jira/browse/COMPRESS-390
You can merge this pull request into a Git repository by running
Github user kvr000 commented on the issue:
https://github.com/apache/commons-compress/pull/21
Additionally, I was thinking about exposing the entry raw stream starting
offset and length via public API so in case of need one can either map it into
memory, directly access the raw data
Github user kvr000 commented on the issue:
https://github.com/apache/commons-compress/pull/21
Update, improving few things:
- made the fields private again
- simplified to single read(long pos, ByteBuffer buf) method
- allocating the instance buffer only for single byte
Github user kvr000 commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/21#discussion_r112838864
--- Diff:
src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java ---
@@ -,14 +1122,11 @@ public int read() throws IOException
Github user kvr000 commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/21#discussion_r112838711
--- Diff:
src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java ---
@@ -1081,16 +1082,26 @@ private boolean startsWithLocalFileHeader
GitHub user kvr000 opened a pull request:
https://github.com/apache/commons-compress/pull/21
COMPRESS-388: Fix concurrent reads performance
Ticket: https://issues.apache.org/jira/browse/COMPRESS-388
Concurrent reads on the ZipFile archive is terribly slow on multiprocessor
