GNOME Bugzilla – Bug 349241
Make file_in_trash invocation async.
Last modified: 2006-08-08 08:55:52 UTC
Browsing an sftp "share" in nautilus is rediculously slow. I am confident the issue is in nautilus and not with gnome-vfs, it's lightening fast in filechoosrs and similar. The entire UI will "lock up" for ten to fifteen seconds each time I change into another directory, and then stay that way for a while after the icons get painted. Here's a backtrace done when it's locked up: Program received signal SIGINT, Interrupt. [Switching to Thread -1226094928 (LWP 26909)] 0xffffe410 in __kernel_vsyscall () (gdb) thread apply all bt
+ Trace 69786
Just to mix things up here is another backtrace from a few seconds later, still feels locked up. (gdb) thread apply all bt
+ Trace 69787
Thread 1 (Thread -1226094928 (LWP 26909))
Guess it's the same except the other thread was done. [Thread -1292895328 (LWP 26975) exited]
It's probably gnome_vfs_find_directory/eel_uri_is_in_trash which can be quite expensive. Maybe we should cache it's value and add it to the NautilusFileAttributes. An async and cancellable version of eel_uri_is_in_trash would be required for this, which also allows us to make the UI non-blocking. For the time being, we can filter out methods that don't support find_directory right in GnomeVFS and save time. However: Thanks, good catch!
Created attachment 69902 [details] [review] Proposed patch The attached patch against GnomeVFS should fix your issue. It was also submitted to gnome-vfs-list for review.
Wonderful, thanks! The patck works great and I can finally get some work done using Nautilus :)
*** Bug 343941 has been marked as a duplicate of this bug. ***
Commited.