unfs3 READ procedure does not end with count==0

This issue was initially reported on SourceForge Link: https://sourceforge.net/p/unfs3/bugs/9/ Reporter: Yaakov Selkowitz Created: 2016-11-22

I have been dealing with the following issue while using gvfs-nfs with a unfs3 server:

https://bugzilla.redhat.com/show_bug.cgi?id=1397289
https://github.com/sahlberg/libnfs/issues/157

In 0.9.22, unfsd was returning 4 bytes of garbage at the conclusion of an async read, causing the operation to never end. With SVN trunk, it is now returning INVALID instead of count==0, causing gvfs to think the operation has failed ("bad address") even though the file is actually transferred.

The libnfs developer believes this is a bug in unfsd, quoting from RFC1813:

offset The position within the file at which the read is to begin. An offset of 0 means to read data starting at the beginning of the file. If offset is greater than or equal to the size of the file, the status, NFS3_OK, is returned with count set to 0 and eof set to TRUE, subject to access permissions checking.

Oct 11 '18 08:10 derfian

Commenter: Peter Åstrand When: 2016-11-28

I've failed to reproduce this problem. Can you clarify what arguments you are calling READ with? I've tried various combinations but dit not end up with INVALID. FYI, I was using a modified version of nfs-cat for my tests, calling with:

/tmp/libnfs/bin/nfs-cat nfs://127.0.0.1/tmp/share/foo.txt

A Wireshark or tcpdump trace would also be very useful.

Oct 11 '18 08:10 derfian

Commenter: Yaakov Selkowitz When: 2016-11-30

As mentioned in the aforementioned bug reports, nfs-{cat,cp} do not exhibit this behaviour. gvfs uses other parts of the libnfs API, however, so gvfs-{cat,copy} will demonstrate this issue.

Oct 11 '18 08:10 derfian