GETATTR does not set fhandle in returned struct about go-nfs HOT 3 CLOSED

overall, there are a few other places where fileid is not set, and linux is unhappy:

[ 1811.830000] NFS: server 192.168.0.10 error: fileid changed
[ 1811.830000] fsid 0:13: expected fileid 0x0, got 0x165b98be2e784cc9
[ 1811.870000] NFS: server 192.168.0.10 error: fileid changed
[ 1811.870000] fsid 0:13: expected fileid 0x0, got 0x15e019a7babe4e62
[ 1811.900000] NFS: server 192.168.0.10 error: fileid changed
[ 1811.900000] fsid 0:13: expected fileid 0x0, got 0x8a54dff6858049b8

one option might be to have ToFileAttribute take the handle as well, to fill in the missing information.

from go-nfs.

in the previous update #97 i intended to switch from using the handle for the fileid to rather using either the underlying fileid when present, or a hash of the full pathname of the file when not. The handle will not be guaranteed to be stable in the same way as the path.

Doing a search, it looks like read-dir still uses the handle for the synthetic fileids for the directory itself. I'll fix that.

I am interested in what's getting us '0x0' file id's - maybe we need to be more aggressive about detecting that when returned from the file system and using path hash if so - the logic right now is that if the stat's os.FileInfo.Sys() is a (*syscall.Stat_t) - then we read the Ino.

from go-nfs.

This should be consistent now with #102

from go-nfs.