when a multi-read was completely beyond the end of file, this caused us to invoke the callback with a 'read-count' of <0 which the callback would treat as a failure.
This would then cause the callback to treat the data pointer as an error string and try to use it for nfs_set_error().
Since the data pointer was actually a real binary databuffer and not an error string this would cause the NFS error string to look like it contained garbage data.
In this case, where the multi-read fails to read any data at all since it if fully beyond end of file, make sure to invoke the callback with a read-count of 0
need to check that status is OK before we start dereferencing the 'export' pointers or else we will segv.
this could happen if trying to pull the list of exports from a host that does not have mountd running, or if we can not connect at all to the host.
when nfs_set_error is called with error_string being the result of a lower layer
problem so it is passed as "rpc_get_error()"
This meant that since free that nfs->rpc->error_string before we reference it a few lines further down in the vasprintf(..., error_string,
adn memory corruption triggers.
Valgrind found this, Valgrind rules!
a read can sometimes span beyond the end of file.
In which case individual smal read chunks beyond the end of file will return OK, 0 bytes of data and EOF==1
For this case, trap when len==0 and ignore these chunks.
Do not update the read-count if / when len is 0.
suggested.
When a read/pread operation that is 'oversize' is issued, the read/pread command will internally chop this up into smaller chunsk and send then concurrently to the server.
As replies come back from the server we add the data to a reassembly buffer
and as soon as all replies have been received we invoke the callback and pass the reassembly buffer back to the application.
Trent Nelson