Hide Forgot
Description of problem: 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, but that's not a very workable solution. Version-Release number of selected component (if applicable): nautilus-2.28.4-15.el6.x86_64 How reproducible: Every time Steps to Reproduce: 1. Mount home directory from NFS server 2. Open a nautilus window and navigate to a folder in the home directory 3. In a terminal create a file in the directory viewed by nautilus and touch a new file there Actual results: New file doesn't appear in the nautilus window until F5 is pressed Expected results: New file appears in nautilus window automatically Additional info: This is on home directories mounted over NFSv4.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
Bizarre - I wasn't making a request, I was reporting a bug.
I think this is actually a bug in gvfs. 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
Related ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/gamin/+bug/383118
This actually seems to be an inotify/nfs4 bug, so am reassigning to kernel.
Created attachment 515072 [details] Simple file monitoring program using gamin Drop this file into a directory and run it (./monitor.py) and then in a different window do things like tocuh junk, and see the signals gamin receives.
The program in the previous comment shows that gamin is receiving the correct signals, so it's not a kernel or nfs4 bug, but must be a bug in gvfs. Reassigning (again).
Upstream bug report: https://bugzilla.gnome.org/show_bug.cgi?id=655271
NFS share isn't provided by GVfs and also monitors aren't implemented in GVfs. NFS is provided by kernel and files are handled like other local files. gvfs-monitor just uses monitors from GIO/GLib in this case, so switching to GLib component. INOTIFY doesn't support NFS fully, FAM should be used instead. This was probably fixed upstream by the patches from: https://bugzilla.gnome.org/show_bug.cgi?id=592211 Those patches are in RHEL 7, could you retest it with RHEL 7?
I am afraid I no longer manage any RHEL 6 or 7 machines so can't do further testing on this unfortunately, sorry - it's over 3 years since I reported this.
This Bugzilla has been reviewed by Red Hat and is not planned on being addressed in Red Hat Enterprise Linux 6 and therefore will be closed. If this bug is critical to production systems, please contact your Red Hat support representative and provide sufficient business justification.
Created attachment 1090676 [details] Patch
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-0968.html
Just a note that the bug 1385040, bug 1388909, and bug 1332753 are obviously a side-effect of this fix...
See also bug 1367175. I don't think that this change was a good idea, please reconsider using FAM only for home directories as it is done in GLib upstream...
Okay, so based on comment 32, we are considering reverting. We can't do FAM only for home directories easily in RHEL6, and suddenly introducing monitoring for other NFS mounts is very problematic. I filed a bug to track reverting. https://bugzilla.redhat.com/show_bug.cgi?id=1399726
Colin, I see that this is "closed ERRATA but no ERRATA link is available. Reopening as such. Also, is there any known workaround for this as backing out a glibc update isn't realistic or really even possible in many configurations
See the following comment for possible workarounds: https://bugzilla.redhat.com/show_bug.cgi?id=1367175#c3