Comment 1 for bug 269954

I'm also running 8.04.1 with linux-image-2.6.24-19-generic (2.6.24-19.41) and I can confirm this problem.

By running 'while true; do date; ls -il .Xauthority ; sleep 1; done' on both my Ubuntu client and Debian etch NFS server (running 2.6.18-6-amd64) I can see that doing a 'ssh -X third-machine' indeed replaces the ~/.Xauthority file in my home directory: the inode number changes on the server but not on my Ubuntu desktop.

With the 'defaults' mount options in my /etc/fstab, my desktop continues to show old ~/.Xauthority inode number and stat() data for 60 seconds, then 'ls -l' starts returning 'ls: cannot access .Xauthority: Stale NFS file handle'. A command line 'stat .Xauthority' returns the same error. Doing any of 'ls .', 'cat .Xauthority >/dev/null', 'touch .Xauthority' will immediately cure this, letting 'ls -l .Xauthority' show the correct and updated info, the same as in the NFS server.

With the 'noac' mount option in my /etc/fstab the behavior is otherwise the same as in the above, but the 60 second timeout disappears and 'stat .Xauthority' starts to return 'Stale NFS file handle' immediately after 'ssh -X third-machine' has replaced the file at 'third-machine' and the NFS server.

With the 'sync' mount option in /etc/fstab the behavior is just like in the case of 'defaults' mount option.

I find it quite likely that this has actually nothing to do with the way OpenSSH does the updating of '.Xauthority' file (i.e. many other applications revise files by replacing them with a new version) but the way '~/.Xauthority' is apparently often used, by just 'stat()'ting it, leads to exposure of this problem. It looks to me more like a kernel NFS client problem.

I'm a bit puzzled why 'lstat64(".Xauthority", ...)' would fail with stale NFS handle whereas a 'open(".Xauthority", ...)' will work just fine---why the former gets out-of-date directory info and the latter gets the correct, updated one?