Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 725178 - Nautilus doesn't automatically refresh for NFS mounts
Summary: Nautilus doesn't automatically refresh for NFS mounts
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: glib2
Version: 6.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Colin Walters
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-23 18:42 UTC by Jonathan Underwood
Modified: 2016-12-12 16:12 UTC (History)
10 users (show)

Fixed In Version: glib2-2.28.8-5.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-11 01:25:04 UTC
Target Upstream Version:


Attachments (Terms of Use)
Simple file monitoring program using gamin (deleted)
2011-07-25 14:24 UTC, Jonathan Underwood
no flags Details
Patch (deleted)
2015-11-06 14:33 UTC, Ashish Shah
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 1289313 None None None Never
Red Hat Product Errata RHBA-2016:0968 normal SHIPPED_LIVE glib2 bug fix update 2016-05-10 22:58:13 UTC

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 Product and 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


Note You need to log in before you can comment on or make changes to this bug.