Bug 725178

Summary: Nautilus doesn't automatically refresh for NFS mounts
Product: Red Hat Enterprise Linux 6 Reporter: Jonathan Underwood <jonathan.underwood>
Component: glib2Assignee: Colin Walters <walters>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0CC: ashishks, ayadav, jkoten, jwright, oholy, rvdwees, rwheeler, swhiteho, tpelka, walters
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: glib2-2.28.8-5.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-11 01:25:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1002711    
Attachments:
Description Flags
Simple file monitoring program using gamin
none
Patch none

Description Jonathan Underwood 2011-07-23 18:42:19 UTC
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.

Comment 2 RHEL Program Management 2011-07-23 19:18:03 UTC
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.

Comment 3 Jonathan Underwood 2011-07-23 21:21:21 UTC
Bizarre - I wasn't making a request, I was reporting a bug.

Comment 4 Jonathan Underwood 2011-07-25 11:46:30 UTC
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

Comment 5 Jonathan Underwood 2011-07-25 11:51:48 UTC
Related ubuntu bug:

https://bugs.launchpad.net/ubuntu/+source/gamin/+bug/383118

Comment 6 Jonathan Underwood 2011-07-25 12:03:56 UTC
This actually seems to be an inotify/nfs4 bug, so am reassigning to kernel.

Comment 7 Jonathan Underwood 2011-07-25 14:24:19 UTC
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.

Comment 8 Jonathan Underwood 2011-07-25 14:25:40 UTC
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).

Comment 9 Jonathan Underwood 2011-07-25 15:23:50 UTC
Upstream bug report:

https://bugzilla.gnome.org/show_bug.cgi?id=655271

Comment 12 Ondrej Holy 2014-12-16 17:25:06 UTC
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?

Comment 13 Jonathan Underwood 2014-12-16 17:50:48 UTC
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.

Comment 17 Chris Williams 2015-09-18 13:53:38 UTC
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.

Comment 19 Ashish Shah 2015-11-06 14:33:27 UTC
Created attachment 1090676 [details]
Patch

Comment 31 errata-xmlrpc 2016-05-11 01:25:04 UTC
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

Comment 32 Ondrej Holy 2016-11-02 09:33:33 UTC
Just a note that the bug 1385040, bug 1388909, and bug 1332753 are obviously a side-effect of this fix...

Comment 33 Ondrej Holy 2016-11-14 09:48:10 UTC
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...

Comment 36 Colin Walters 2016-11-29 15:43:36 UTC
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

Comment 37 Joe Wright 2016-12-12 15:25:30 UTC
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

Comment 39 Ondrej Holy 2016-12-12 16:12:10 UTC
See the following comment for possible workarounds:
https://bugzilla.redhat.com/show_bug.cgi?id=1367175#c3