GNOME Bugzilla – Bug 655271
gvfs does not correctly monitor files on NFS v4 mounted directories.
Last modified: 2014-12-16 17:31:59 UTC
For NFS mounted directories, Nautilus doesn't automatically update the contents of a directory window when the contents of that directory change. Pressing F5 to refresh the window does successfully update the contents. I opened a nautilus window looking at my home directory. In one window, I did a gvfs-monitor /home/jgu, and in another window I ran the following sequence of commands: touch file chmod +x file mv file FILE Only after the mv command does the file appear in the nautilus window In the gvfs-monitor window I see: Directory Monitor Event: Child = /home/jgu/file Event = ATTRIB CHANGED Directory Monitor Event: Child = /home/jgu/file Event = CHANGES_DONE_HINT Directory Monitor Event: Child = /home/jgu/file Event = ATTRIB CHANGED Directory Monitor Event: Child = /home/jgu/file Event = DELETED Directory Monitor Event: Child = /home/jgu/FILE Event = CREATED So, weirdly, the touch file command doesn't seem to trigger a CREATED event in gvfs. Also, doing a rm FILE makes the file disappear from the nautilus window, as expected, and the following appear in the gvfs-monitor window: Directory Monitor Event: Child = /home/jgu/FILE Event = DELETED Redhat bugzilla report: https://bugzilla.redhat.com/show_bug.cgi?id=725178 Ubuntu bug report: https://bugs.launchpad.net/ubuntu/+source/gamin/+bug/383118 Incidentally, gamin does successfuly receive file creation events, which (I think) rules out a kernel/nfs4 bug.
I was going to ask earlier... sometimes NFS listings are cached - can you verify by doing "ls -al" that the file is there? (on client side) Preferably test this with freshly mounted filesystem (umount & mount cycle should be fine).
Yes, I can confirm that on the client once I've done a "touch file" that ls -al on both the client and the server shows file as present, but it never appears in Nautilus, and no CREATE event happens.
I find it odd that creating the file does trigger a ATTRIB CHANGED event, but not a CREATED event. Suggests the bug is perhaps in one of the GFileMonitor methods. I can't actually work out where they come from though :).
OK, thanks for confirming this. Can you please post your NFS mount options? Are there any symlinks in the path? Just checked on my machine, I'm getting proper CREATED, ATTRIB CHANGED and CHANGES_DONE_HINT events. We need to find out how this happens.
Thanks for taking a look. The home directories are actually automounted on login with options -rsize=8192,wsize=8192,intr,sec=krb5 On the server, they are exported with: /export 128.40.5.0/24(sec=krb5,fsid=0,rw,nohide,insecure,no_subtree_check,async) /export/users 128.40.5.0/24(sec=krb5,rw,nohide,insecure,no_subtree_check,async) Just to re-emphasize, this is all nfs v4 - the ubuntu bug report indicates that this problem doesn't occur with nfs v3. On the server, /export/users is actually a bind mount: /storage/users on /export/users type none (rw,bind) There's nothing symlinked at all (i.e. I can reproduce this with a test account with only the skel files and the directories that Gnome creates on first login).
As another data point if I am at machine A with a nautilus window open looking at my nfs mounted home directory, and on machine B which also nfs mounts the home directory when I create and mv a file, it never shows up in nautilus until I refresh. I realize this is even more of a tricky situation to get right.
Interestingly, installing Thunar 1.3, which I believe uses gio/gvfs, on the same machine does not manifest the problem as originally reported. It does still manifest the more complicated 3 machines scenario in the last comment tho.
There's been NFS monitoring changes in GIO - see bug 592211. Any chance to retest this on recent glib version?
Works for me...
It was probably fixed with bug 592211. If you still see this issue, please reopen.