Hello!
I suggest to extend the test to cover the case with malformed input.
Would you please review the suggested change?
http://cr.openjdk.java.net/~igerasim/7021870/0/webrev/
I haven't created the bug id for the change yet.
Will create one if you agree that the change is reasonable.
The main
Hello Sherman!
Thank you for the review!
While I agree with you that current implementation of
ZipInputStream.available() is not what it's supposed to be, I doubt it
is the only cause of the issue.
Please consider the following example.
Zip archive (z.zip) consists of two entries: f1 and f2.
A small correction to the recipe for failure.
The failure is reproduced when a SINGLE byte is appended to the gzip
archive.
In the scenario below the echo command appends TWO bytes. These two
bytes are interpreted as a wrong gzip header and get successfully ignored.
On 13.05.2013 16:23, Ivan
Ivan,
It's a fair assessment to say ZIS.available() is not the only cause... though
I don't think it's that easy to really craft a real test case to demonstrate
the
failure with a malformed gzip entry inside a zip file. At least I don't think
I can create one without sitting down with some real
On 10/05/2013 23:48, Xueming Shen wrote:
:
So the proposed fix is more a workaround for this available() issue. The
alternative is to fix the issue directly, for example, to change the
ZIS's
available implementation to something like
public int available() throws IOException {
Hello everybody!
GzipInputStream uses SequenceInputStream to concatenate the underlying
stream with some data that reside in memory.
SequenceInputStream is implementing in such a way that it closes the
stream when it reaches EOS.
The solution is to wrap the underlying stream with extended
The fix looks reasonable to me.
Mike
On May 10 2013, at 01:03 , Ivan Gerasimov wrote:
Hello everybody!
GzipInputStream uses SequenceInputStream to concatenate the underlying stream
with some data that reside in memory.
SequenceInputStream is implementing in such a way that it closes the
The proposed fix does solve the issue.
However it appears it does not fix the root cause that triggers this problem.
The root cause, or the direct trigger of this bug is the fact that
ZipInputStream
.availble() is really NOT reliable to tell us whether or not there is any byte
available to be
