unascribed opened a new pull request, #360:
URL: https://github.com/apache/commons-compress/pull/360
The Pack200 decompressor expects `read` to always return the amount of bytes
it requested. This is *usually* true for raw input streams, such as File or
ByteArray, but breaks down when combined with other block-based decompressors.
For example, combining an LZMAInputStream with a Pack200 decompressor results
in an error similar to the following if a file falls between block boundaries:
```
Exception in thread "main"
org.apache.commons.compress.harmony.pack200.Pack200Exception: Expected to read
48873 bytes but read 3274
at
org.apache.commons.compress.harmony.unpack200.FileBands.processFileBits(FileBands.java:87)
at
org.apache.commons.compress.harmony.unpack200.Segment.readSegment(Segment.java:460)
at
org.apache.commons.compress.harmony.unpack200.Segment.unpackRead(Segment.java:514)
at
org.apache.commons.compress.harmony.unpack200.Segment.unpack(Segment.java:484)
at
org.apache.commons.compress.harmony.unpack200.Archive.unpack(Archive.java:198)
at com.unascribed.unpacktest.UnpackTest.main(UnpackTest.java:20)
```
Pack200 is *intended* to be combined with other forms of compression, so
this is a major issue in some cases.
This reimplements the portion of the method to use `read` correctly, keeping
track of how much has been read. I did not address the TODO as I don't believe
there's a good way to implement it with the current architecture of the
decompressor.
The file I'm having issues with is a Pack200+LZMA file that does not contain
any class files. Kind of a weird case, but it's what I'm stuck with, and
Commons Compress is the only real extant Pack200 decompressor for modern Java.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
