Update FuseFileSystemProvider.java - return the correct value from read method

[NaamaGertel]

when reading from the buffer in line 296, if we got -1 it means 0 bytes were read, so we need to return 0, because this is the right value for n

[guss77]

I think the problem here is conflicting read() semantics: FuseFileSystemProvider.java is an adapter between POSIX semantics and Java semantics, as can be seen in the patched read() method - it implements the POSIX.1-2001 read() method by calling the SeekableByteChannel.read() method

Both POSIX and Java methods return values are the number of bytes read - if any bytes were read. The difference lies in error detection and the handling of end-of-file scenario, which the original code (before this patch) completely ignored: if the Java's read() did not return a positive number, we just return its result as the POSIX read() result.

Because POSIX read() is expected to signal end-of-file by returning 0 and an error condition by returning -1, while Java is signalling end-of-file by returning -1 and an error condition by throwing an exception (that the current FuseFileSystemProvider.java is catching and handling correctly), if an end of file is encountered on entry to FuseFileSystemProvider.read() - which happens everytime when trying to read a 0-sized file, but could also happen at other times - then read() ignores the semantic difference and causes an error to be detected by the caller, even though no error has occured and the POSIX sepecification requires it to return 0.

This patch appears to fix the problem - if no exception occured, read() must never return a negative number: if Java's read() did not return a positive number, return 0.