Hello. This is my first time posting here so I apologize if this is the
wrong forum. I wanted to bring up an issue in the GZipInputStream which
was first identified in 2011, confirmed as a bug, and then never resolved.
When reading certain GZIP files from certain types of InputStreams the
GZIPIn
On Mon, 5 Feb 2024 23:53:06 GMT, Archie Cobbs wrote:
>> `GZIPInputStream`, when looking for a concatenated stream, relies on what
>> the underlying `InputStream` says is how many bytes are `available()`. But
>> this is inappropriate because `InputStream.available()` is just an estimate
>> and
On Sun, 17 Mar 2024 22:53:55 GMT, Archie Cobbs wrote:
>> `GZIPInputStream`, when looking for a concatenated stream, relies on what
>> the underlying `InputStream` says is how many bytes are `available()`. But
>> this is inappropriate because `InputStream.available()` is just an estimate
>> and
Hi Brian,
Thanks for looking into this! That sounds like it would work for my use
case. Anything that returns a result instead of a crash would be a huge
improvement. My main concern is definitely unix/bsd/osx systems, I don't
have a good sense of how pipes work on windows or if there is an an
On Tue, 22 Oct 2024 02:40:44 GMT, Brian Burkhalter wrote:
>> Add `isOther` and `available` methods to `FileChannelImpl` and the
>> interfaces to native code and use these in `ChannelInputStream` to work
>> around cases where a wrapped `FileChannelImpl` is not really seekable.
>
> Brian Burkhalt
If I wanted to contribute a patch, can you suggest what you think would be
the best path forward?
I've listed some options but I'm sure there are more:
1.It seems like amending the underlying issue in the native code
underlying FileDispatcherImpl.seek() so that it returns a value when asked
f
e any way to get this on the radar? It's been a continuous source
of confusing errors in our codebase for years.
Thank you,
Louis Bergelson
