Hi Louis,
You’re welome!
It definitely handles the “/dev/stdin” case. Other possible fixes are also
being considered.
The Windows case is yet to be investigated, but if needed, does not have to be
part of this issue.
Brian
On Oct 3, 2024, at 11:35 AM, Louis Bergelson wrote:
Thanks for look
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
Hi Louis,
I have a functional patch implemented. It adds available() to FileChannelImpl
which then uses it if the SeekableByteChannel is a FileChannelImpl. The patch
only had the UNIX changes for now; I’ve not investigated Windows enough to know
what to do there.
Does that sound reasonable?
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
The InputStream created over the FileChannel assumes that the
FileChannel is connected to a regular file, which isn't the case with
this character special file and several other pseudo devices. As you've
found, many of the methods defined by FileChannel doesn't make sense
with these devices.
