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 to nd.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 seeks documentation: "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
