There are still places where FileID zero is returned, which confuses linux about go-nfs HOT 9 CLOSED

Looking a bit deeper, I think every call that tryStat ought to be checked to see if the return attr needs fileid set.

from go-nfs.

or, tryStat should take an [optional] handle to fill in fileid maybe.

from go-nfs.

Just FYI, I'm also seeing this on OSX.
Once I mount, the second time I ls a directory:
ls: nfs/etc: Stale NFS file handle
lrwxr-xr-x 1 root wheel 11 Nov 18 10:13 etc

from go-nfs.

This may be related to a couple of the other issues that have surfaced, as we partially went from always reporting fileid 0 to sometimes reporting the underlying inode.

from go-nfs.

Closing this as also resulting from the issue fixed in #102

from go-nfs.

oh darn. things seemed to work, but the problem is back, in spades. To recreate on osx:
osfnfs / 2049
sudo mount -t nfs -o nfsvers=3,port=2049,mountport=2049,nolock 127.0.0.1:2049 nfs
ls nfs # first time it shows the directory
ls nfs/usr
r.minnich@2840nrd-rminnic tmp % ls nfs/usr/
ls: fts_read: Stale NFS file handle

and in the osnfs window:
2023/12/20 20:44:30 [ERROR] call to 0x1006d5bb0 failed: Invalid file handle
2023/12/20 20:44:30 [ERROR] call to 0x1006d5bb0 failed: Invalid file handle
2023/12/20 20:44:30 [ERROR] call to 0x1006d5bb0 failed: Invalid file handle
2023/12/20 20:44:30 [ERROR] call to 0x1006d5bb0 failed: Invalid file handle

over and over :(

from go-nfs.

fileid should be getting forwarded properly through tryStat now.

• I wonder if this is an issue with FileID's still ,or is now an issue with handles?

from go-nfs.

I'm also still getting stale NFS file handles while using the latest version of the library (269dbac, at the time of writing).

pedro@Pedros-MacBook-Pro Downloads % ls -@Oahl ~/Applications                                                                    
total 2924
dr-xr-xr-x@   5 root   wheel  -  160B 31 Dec  1969 .
	com.apple.FinderInfo	  32B 
drwxr-x---+ 103 pedro  staff  -  3.2K 30 Dec 21:02 ..
-rw-rw-rw-    1 root   wheel  -  1.4M 30 Dec 21:35 .VolumeIcon.icns
-rw-rw-rw-    1 root   wheel  -  406B 30 Dec 21:35 ._.

ls: /Users/pedro/Applications/IntelliJ IDEA CE.app: Stale NFS file handle
lrwxr-xr-x    1 root   wheel  -  116B 31 Dec  1969 IntelliJ IDEA CE.app

ls: /Users/pedro/Applications/Sublime Text.app: Stale NFS file handle
lrwxr-xr-x    1 root   wheel  -   91B 31 Dec  1969 Sublime Text.app

ls: /Users/pedro/Applications/Visual Studio Code.app: Stale NFS file handle
lrwxr-xr-x    1 root   wheel  -  105B 31 Dec  1969 Visual Studio Code.app

pedro@Pedros-MacBook-Pro Downloads % ls -@Oahl ~/Applications
ls: IntelliJ IDEA CE.app: Stale NFS file handle
ls: Sublime Text.app: Stale NFS file handle
ls: Visual Studio Code.app: Stale NFS file handle
total 2921
dr-xr-xr-x@   5 root   wheel  -  160B 31 Dec  1969 .
	com.apple.FinderInfo	  32B 
drwxr-x---+ 103 pedro  staff  -  3.2K 30 Dec 21:02 ..
-rw-rw-rw-    1 root   wheel  -  1.4M 30 Dec 21:38 .VolumeIcon.icns
-rw-rw-rw-    1 root   wheel  -  406B 30 Dec 21:38 ._.
ls: fts_read: Stale NFS file handle

The problem seems related to symbolic links. Above, all *.app are symbolic links to directories using their absolute paths. I'm also getting this error message on the client: nfs loadattrcache vnode changed type, was 5 now 2. Meaning that the vnode type was VLNK and now is VDIR.

I've added some logging, and my FS implementation is indeed returning different vnode types for those files. But that's because the NFS library is calling billy.Filesystem#ReadDir, that "If the entry denotes a symbolic link, Info reports the information about the link itself, not the link's target.", and then it calls billy.Filesystem#Stat instead of billy.Filesystem#Lstat. So the vnode type will always change.

from go-nfs.

This patch addressed my problem: t0rr3sp3dr0@ab06230

But I'm not sure if changing the implementation of tryStat to always use billy.Filesystem#Lstat is something we can do. I think we need a tryLstat and move to this new function on a case-by-case basis.

from go-nfs.