Red Hat Bugzilla – Bug 399071
Nautilus pauses when opening folders due to unrelated automount
Last modified: 2015-03-03 17:31:43 EST
Description of problem: When double-clicking on a folder in Nautilus, it check to see if an automounted directory is available and waits for autofs to timeout. This causes a 15-20 second delay every time you open a folder. Version-Release number of selected component (if applicable): nautilus-2.20.0-6.fc8 How reproducible: Steps to Reproduce: 1. Double-click on a folder on the local desktop 2. Wait several seconds 3. Window finally opens Actual results: Long delay before window opens Expected results: Window should open instantly Additional info: Running "strace -e access" revels: access("/home/doug/Desktop", R_OK|W_OK) = 0 access("/home/doug/Desktop", X_OK) = 0 access("/home/doug/.Trash", F_OK) = 0 access("/home/doug/Desktop", R_OK|W_OK) = 0 access("/home/doug/Desktop", X_OK) = 0 access("/home/doug/Desktop", F_OK) = 0 access("/home/doug/.nautilus", F_OK) = 0 access("/net/nfssrv1/export/dropbox", F_OK <unfinished ...> The access is to a old directory on an old NFS server. Where is this reference being saved? Thanks, Doug
Here is a pstack trace of the stall: #0 0x0000003516ec6ef7 in access () from /lib64/libc.so.6 #1 0x0000003519a21f2d in g_file_test () from /lib64/libglib-2.0.so.0 #2 0x0000000000490662 in nautilus_bookmark_uri_known_not_to_exist () #3 0x000000000044516a in update_places () #4 0x000000000044571a in nautilus_places_sidebar_create () #5 0x000000000043f19f in nautilus_navigation_window_show_sidebar () #6 0x000000000043f56b in nautilus_navigation_window_show () #7 0x000000351b20b1a9 in g_closure_invoke () from /lib64/libgobject-2.0.so.0 #8 0x000000351b21ac7d in g_cclosure_marshal_VOID__ENUM () #9 0x000000351b21bc73 in g_signal_emit_valist () #10 0x000000351b21be43 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #11 0x000000351f48da2c in gtk_widget_show () #12 0x00000000004598d9 in nautilus_window_show_window () #13 0x0000000000462579 in finish_loading_if_all_metadata_loaded () #14 0x000000000049a6b5 in ready_callback_call () #15 0x000000000049c69f in call_ready_callbacks_at_idle () #16 0x0000003519a2edf3 in g_main_context_dispatch () #17 0x0000003519a320ed in g_cclosure_marshal_VOID__ENUM () #18 0x0000003519a323fa in g_main_loop_run () from /lib64/libglib-2.0.so.0 #19 0x000000351f35b0c3 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0 #20 0x000000000043c934 in main () #21 0x0000003516e1e074 in __libc_start_main () from /lib64/libc.so.6 #22 0x0000000000428ef9 in _start ()
Further investigation show that the NFS automount path was cached in $HOME/.gtk-bookmarks and was not visible from the GUI, so it could not be removed without manually editing the file.
I would suggest that invalid paths such a stale/failed NFS mounts either be deleted or exposed through the GUI, maybe with a dialog offering to delete the bookmark.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.