potential bug in SeekablePathStream.read()

[lbergelson]

I noticed that it looks like SeekablePathStream().read() could potentially erroneously return a 0 when the underlying SeekableByteStream implementation doesn't guarantee that either a byte is read or -1 is returned on end of stream. This is possible with non-blocking SeekableByteChannels. It's not clear to me if anything guarantees that the channel implementation provided by Files.newByteChannel is always non-blocking.

@Override
    public int read() throws IOException {
        oneByteBuf.clear();
        int n = sbc.read(oneByteBuf);
        return n == 1 ? oneByteBuf.array()[0] & 0xff : n;
    }

If seems like we probably want to retry reading if n = 0, (or throw and say that it requires a blocking channel to back it...) .

@tomwhite You originally wrote this, maybe you found something that demonstrated that getting a 0 back would be disallowed by any FileSystemProvider implementations?

[tomwhite]

I don't remember finding that 0 was specifically disallowed. So this does look like a bug. I'm not sure we'd want to retry here (who decides the policy?), I think throwing an exception would be appropriate.