After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 527602 - Browsing a mount containing a broken bookmark causes nautilus to stop responding
Browsing a mount containing a broken bookmark causes nautilus to stop responding
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: Navigation
2.22.x
Other All
: Normal critical
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-04-11 18:44 UTC by Bryan
Modified: 2008-11-10 14:35 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Bryan 2008-04-11 18:44:35 UTC
Please describe the problem:
I have a large number of samba bookmarks where I work, and sometimes the folders get changed (renamed) by someone.  I will navigate to a directory that should contain one of these renamed directories according to the bookmark, but the folder has been renamed.  Nautilus will sit and chug, trying to do who-knows-what.  It takes several minutes at least.  Sometimes it comes out of this, and sometimes I have to kill nautilus, and then gvfs-smb, and when they restart I'm OK again.  But, I can't even browse to that base directory again or the problem repeats.  I fixed it in my particular situation by navigating to the directory, writing down the new name of the folder (luckily I guessed this was the problem) and then editing the bookmarks (after killing nautilus and gvfs-smb and letting them restart) by going to an unaffected directory and clicking "Bookmarks"->"Edit Bookmarks".  This is new in Hardy Heron, and I'm guessing it is a result of the switch to gvfs.

Steps to reproduce:
1. Create a bookmark to a nonexistent leaf of a samba share you have mounted
2. Go to that bookmark OR go to the topmost directory which does exist in the bookmark
3. Computer chugs away, presumably trying to read the non-existent directory.


Actual results:
My computer effectively freezes as the CPU and network interface are pegged.  However, if I'm patient I can try and wait till the connection times out or I am able to kill nautilus and gvfs-smb, I am able to use the PC again.

Expected results:
The broken link is detected without 3 solid minutes of CPU time.

Does this happen every time?
Yes.

Other information:
Ubuntu Hardy Heron.  Current.  I can help troubleshoot this.  It should be trivial to fix and is similar to a network bug I helped find and fix with the multiload applet.  It's probably a consequence of the library treating a samba share like a local file-system.
Comment 1 André Klapper 2008-10-18 22:34:06 UTC
Is this still an issue in 2.24 (Intrepid Ibex)?
Comment 2 brywilharris 2008-11-07 21:32:03 UTC
No.  I upgraded a week or so ago and can no longer trigger this bug. 
Comment 3 brywilharris 2008-11-07 21:36:09 UTC
This bug does not affect (8.10) Ibex.
Comment 4 Cosimo Cecchi 2008-11-08 00:26:32 UTC
Thanks for the follow-up, closing.
Comment 5 Bryan 2008-11-10 13:38:46 UTC
This affected Gnome 2.22.  Ibex is 2.24.  I bet the bug still affects 2.22.  :-(
Comment 6 André Klapper 2008-11-10 13:53:18 UTC
Bryan: Please be exact. "2.22" is quite vague, "2.22.3" or "2.24.1" is more helpful.
GNOME will not fix bugs in 2.22 anymore - feel free to ask your distributor (and point to an exact commit that fixed this if possible) to backport patches, or even better: Upgrade to 2.24.
Comment 7 Bryan 2008-11-10 14:35:24 UTC
OK.  The bug is still there in the Nautilus 2.22.5.1 shipped with Ubuntu Hardy Heron, 8.04.1, with all updates as of 10 Nov 2008.  
Gnome version is: 2.22.3, build date 07/09/2008.
Kernel Version on the test machine is 2.6.24-21-eeepc.  

This was tested over a WPA wifi connection, though the original test machine (now updated to Ibex, and therefore 2.24(.1)) was a wired connection.  I get the same effect over a wired and wireless connection.  The computer pegs the CPU until the misbehaving processes are killed.