GNOME Bugzilla – Bug 170626
accessing (remote) folders needs threading
Last modified: 2010-07-04 23:18:47 UTC
Nautilus appears to lock ( completely unresponsive ) while accessing folders. This is most obvious when you have a network share mounted, or as in my case, have a *lot* of network shares mounted. I have 5 nfs shares and 4 smbfs shares, and this makes nautilus quite painful to use in certain circumstances. One such circumstance is loading gnome. The desktop locks on startup, just before the background image and network share icons are displayed. It can take anything up to 30 seconds for the startup to complete. Another circumstance is whenever I browse to the /mnt/ folder, which obviously has all my network shares attached. For example, when I click the 'file open' button in OpenOffice and browse to the /mnt/ folder, nautilus ( and OpenOffice ) lock while all the network shares are polled. It would be supurb if all this polling happened in the background, via separate threads, and the status of polling were displayed somewhere, eg: - in the Open / Save dialog - in the nautilus window This way, you don't necessarily have to block the use of the open / save dialog. People will be able to see that not all network shares have been polled yet from the status indicator ... possibly with some wizz-bang animation :) ... and they can proceed if they wish ( ie if the particular share they want is accessible ) even though other shares have not been polled. Alternatively, they can sit and wait while the status of the shares is dynamically updated.
Do you still see this locking behavior?
*** Bug 324360 has been marked as a duplicate of this bug. ***
Yes I still see this. Nautilus-2.12.2
*** Bug 317569 has been marked as a duplicate of this bug. ***
Mentionned on https://launchpad.net/distros/ubuntu/+source/nautilus/+bug/40740 too
*** Bug 355485 has been marked as a duplicate of this bug. ***
*** Bug 330908 has been marked as a duplicate of this bug. ***
this still applies for 2.16 I can see this when accessing a slow sftp server. It grinds down all nautilus windows completely to a halt. Given the number of complaints I'll confirm this report.
Maybe Nautilus is pulled down by the synchronous eel_uri_is_in_trash call, which is bug 46899?
*** Bug 349908 has been marked as a duplicate of this bug. ***
Has this to some extent been mitigated with the GIO port?
I do not believe we can verify this today since some remote folders (sftp, ssh etc.) have not been implemented yet in GIO/GVFS.
SFTP still causes this problem, and so I do not believe it to be the case anyway. Unless SFTP is not through GVFS/GIO. Not really up to speed on it. Hope this is useful.
State of gvfs thread here http://www.mail-archive.com/desktop-devel-list@gnome.org/msg12050.html Matthew, did you test with gvfs from svn? Hmm o.k just saw on desktop devel list "gvfs comes with a set of backends, including trash support, sftp and smb. More backends are being worked on." That was Alex L last November.
Sadly, I do not have enough time to manually mess with svn, etc; so I was using the gvfs from ubuntu hardy, and am fairly certain the issue remains in the latest packages available there (0.1.7). Kind Regards, Matthew
I haven't tested with gvfs. May be http://bugzilla.gnome.org/show_bug.cgi?id=350146 is related to these bug. Actually it is: nautilus is slow when accessing slow directories, it doesn't matter whether there are gvfs or real mounts. So you don't need special backends to test, the bug should be reproducible with any NFS/SMB/FUSE resource
*** Bug 350146 has been marked as a duplicate of this bug. ***
Still a problem with nautilus with gvfs (such as version 2.30)? I haven't noticed nautilus to lock while browsing slow shares...
This has been obsoleted with the migration to GIO.