#9 READ procedure does not end with count==0

[Yaakov Selkowitz]

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.

[Peter Åstrand]

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.

[Yaakov Selkowitz]

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.