Red Hat Bugzilla – Bug 51060
fam doesn't update local files modified over nfs.
Last modified: 2008-05-01 11:38:00 EDT
If I export a filesystem via nfs and change its contents from a remote
machine, nautilus on the local machine doesn't update to reflect these
changes. This seems odd, since the files _are_ local...
Are you running knfsd?
If so, i think i know what is happening. The write patch of knfsd doesn't
trigger the a dnotify event.
Erm. I meant write path.
I am running knfsd.
Hm. I actually tested this, and it works for me (tm).
I wonder why it doesn't work for you...
Actually, it seems there are a few other files it doesn't work for. Saved
documents in emacs or AbiWord occasionally show up with zero size until
I refresh the window ... very strange.
I'll let you know if I figure out what the pattern is.
If someone wanted to look at the emacs problem, one would first
read the emacs doc's on how it does backup files; it has a number
of modes, not all obvious in operation.
I can't reproduce this.
This seems to be a more general problem than just nfs. Sometimes, files saved
from Abiword, Gnumeric, or Staroffice lose their size info (they show up on the
desktop sized 0 or 4k.) I also sometimes see directory item counts remain
unchanged after creating files there from the shell.
Rawhide/RHN hasn't had updated packages for some time, so maybe I'm just running
outdated/broken packages. fam is 2.6.4-11, xinetd is 2.3.3-1, nautilus is
1.0.4-40, kernels are 2.4.9-0.5 and -ac16.
Ok, this is odd. It seems even files copied from within Nautilus can show up
with zero sizes.
Any other info I can provide? I haven't seen anything like this reported
elsewhere, and Nautilus seems to be behaving pretty badly in general, so I might
just have a foobar'd configuration.
The nonchanging directory counts is "correct". Nautilus does not watch all
subdirs of the current dir. That would be a tad to expensive.
Ok. I see this now.
I think it is a race between AbiWord, fam and Nautilus.
Nautilus gets the first notification of change, when the file is truncated, but
then for some reason does not get, or ignores the rest of the changes.
This is a race in fam.
If you get more than one change of a file in the same second fam cannot detect
that, since the resolution of ctime is only one second.
This will be sort of hard to fix. I think it involves holding back the change
events for one second.
This is fixed in 2.6.4-13