Bug 118922

Description of problem:
using FC1 as an NFS client (RHEL 3.0 NFS server) has problems with
'Stale NFS Handle' errors, which appear to be caused be the client
attempting to reuse a filehandle that is no longer valid.

more info below.

Version-Release number of selected component (if applicable):
FC1, all up-to-date as of 3/22/04.  kernel 2.4.22-1.2174.nptl

bug does NOT occur when client is RHL 9.0 or RHEL 3.0

How reproducible:
always

Steps to Reproduce:
1. ssh -X myserver date (exits after printing date)
2. xauth list (very soon after step 1, I believe within 1 second)
3. xauth list (as many times as you want. things are now buggered)
 
Actual results:
/usr/X11R6/bin/xauth: error in locking authority file
/home/sun1/david/.Xauthority

Expected results:
works.

Additional info:
note: local home directory, and home directory on 'myserver' are nfs
mounted from same nfs server. 

ultimately, what happens is that the first step causes a 'xauth list'
on the client (i.e. at least an NFS lookup on .Xauthority file) then
an 'xauth add' and 'xauth remove' on 'myserver'.  it is the latter
that triggers the bug, because 'xauth remove' (use 'strace -f -o out
sshd -e -d -p <someport>' on myserver to catch this) ends up creating
a new .Xauthority file (i.e. creates new file, unlinks .Xauthority,
and renames new file to .Xauthority, the end result being that the
inode of .Xauthority changes).

now when step 2 is run, 'xauth list' attempts to open .Xauthority
again, but the NFS client uses the stale (cached) nfs file handle
(BUG), and so 'xauth list' receives 'Stale File Handle' error visible
to user space.  

xauth list then exits, having already created .Xauthority-c and
.Xauthority-l

the third step, xauth list again sees the lockfiles and exits with the
error.

isn't there some rule about close-to-open consistency?