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. This one is fixable with a special side channel to
to FCI to support the available method, just hasn't been a priority as
the. issue has always existed.
-Alan
On 02/10/2024 16:26, Louis Bergelson wrote:
Hello,
There's a long standing bug when using Files.newInputStream() with
unix non-regular files. (/dev/stdin , /dev/random/ etc). It was
reported in JDK-8233451
<https://bugs.openjdk.org/browse/JDK-8233451> but it doesn't seem like
there's been much movement on it. It's causing repeated problems in
our code base because it means reading from a piped input has to be
treated differently than reading from any other input. We've made an
effort to move away from using File inputs and using Paths everywhere,
but this causes issues with that.
It's very easy to trigger:
InputStream inputStream =
Files./newInputStream/(Paths./get/("/dev/stdin/"));
inputStream.available();// throws the following
java.io.IOException: Illegal seek
at java.base/sun.nio.ch.FileDispatcherImpl.seek0(Native Method)
at
java.base/sun.nio.ch.FileDispatcherImpl.seek(FileDispatcherImpl.java:78)
at java.base/sun.nio.ch.FileChannelImpl.position(FileChannelImpl.java:344)
at
java.base/sun.nio.ch.ChannelInputStream.available(ChannelInputStream.java:114)
The relevant line is here in FileChannelImpl.position();
/ // in append-mode then position is advanced to end before writing/
p = (append) ? nd.size(fd) : nd.seek(fd, -1);
Since the channel is an input it always has append == false which
means it always results in a call tond.seek(fd, -1)
This throws the Illegal Seek exception.However, I believe this is not
ideal behavior, because a call to seek with a value of -1 should be
interpreted as a request for the current file position rather than a
request to seek.
From seeksdocumentation: "Sets or reports this file's position *If
offset is -1, the current position is returned *otherwise the position
is set to offset."
It seems like returning either 0, -1, or a count of the number of
bytes read from the channel so far would all be better behavior than
throwing in this case.
It should be noted that calling position() on this channel is
immediately fatal which is also extremely unexpected.
If changing that behavior isn't possible, it might make sense to have
the default file system provider for Files.newInputStream return a
different implementation when reading from a unix irregular file.
The mismatch happens because it treating all files as seekable when
they are strictly not.
Is there 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
