RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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: 1002711
TreeView+ depends on / blocked
 
Reported: 2011-07-23 18:42 UTC by Jonathan Underwood
Modified: 2021-06-10 10:37 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:
Embargoed:

Attachments (Terms of Use)
Simple file monitoring program using gamin (366 bytes, text/plain)
2011-07-25 14:24 UTC, Jonathan Underwood 		no flags Details
Patch (8.56 KB, patch)
2015-11-06 14:33 UTC, Ashish Shah 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 1289313 0 None None None Never
Red Hat Product Errata RHBA-2016:0968 0 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 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.