GNOME Bugzilla – Bug 536437
dragging files over sidebar blocks totally Nautilus
Last modified: 2008-07-26 01:15:15 UTC
I'm using the navigation mode (not the the spatial) with the place sidebar active. I wanted to move files from the nautilus window to the desktop, when the pointer passed over the sidebar, the pointer became blocked during several seconds. I can see this behavior regularly. I'll try to have strace or gdb strack trace.
I reproduced it. My guess is this happens because in nautilus-dnd.c:check_same_fs () we do sync I/O. I think a solution for this would be storing filesystem_id in NautilusFile and use its caching facility to obtain the information. Also, I think this is also what triggers bug 531435.
*** Bug 531435 has been marked as a duplicate of this bug. ***
The same behaviour can be triggered by passing over desktop files that are web links (i.e., such as those gained by dragging a URL from epiphany to the desktop).
*** Bug 540484 has been marked as a duplicate of this bug. ***
Created attachment 113533 [details] [review] patch for gvfsdnetwork to attempt to hide this problem This will hide the problem for a lot of people, I think, but it comes at a rather nasty price. This patch makes the network backend mount instantly and make same_fs() return much more quickly, but as a result, we have to scan the network every time we enumerate files on the virtual file system. If your network is extraordinarily slow, this means that Nautilus may spin a while looking for servers (but, importantly, will not block; you will still be able to use other windows and such). I'm not exactly sure how evil this will be as my home network has about three "servers", and we're already getting reports of Nautilus used in locations with thousands of servers, so it really needs to be tested to see if this is a huge hindrance to the usability of this backend for those people. (Of course, an even better fix is a rewrite of some of the internals of this backend to do async/threaded I/O, but that's best saved for 2.24+.) So while this solves a couple of other problems, it is definitely the wrong fix for this problem. We still need to rewrite this code in Nautilus, as this behavior will manifest for any other file system that may take a while to query_info.
The issue has been fixed in Nautilus 2.25.1, with a solution similar to what Cosimo proposed in comment 1. Closing.
*** Bug 544787 has been marked as a duplicate of this bug. ***