Re: Illegal Seek when using File.newInputStream()

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

Re: Illegal Seek when using File.newInputStream()

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

Re: Illegal Seek when using File.newInputStream()

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?

Re: Illegal Seek when using File.newInputStream()

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

Re: Illegal Seek when using File.newInputStream()

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.

Illegal Seek when using File.newInputStream()

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 but it doesn't seem like there's been much movement on it. It's causing repeated prob