GNOME Bugzilla – Bug 725939
new search mode on sftp renders nautilus unusable
Last modified: 2015-09-02 21:17:23 UTC
[[ Please excuse the tone of this report. I've tried to write it in a way that conveys the level of frustration that we are inflicting on our users -- in this case, me. ]] When using nautilus on sftp shares, I often try to use typeahead search to quickly jump to the name of a folder that I already see in the window. Despite years of expectations developed on every computer system I've ever used, this engages the new search mode. Oh right. That's unfortunate. OK. I can deal with this -- after a brief flicker, the thing I had already found with my eyes will reappear again in a new location. I hit enter to go inside of that folder. After doing that once or twice, though, things suddenly aren't working very well. I can no longer access files on my server -- it's like the connection has gone dead. I close nautilus and try to start it again. Nautilus won't restart. I start to get the feeling that this has something to do with this new search mode that I never wanted to use anyway. It's pretty frustrating that merely typing a letter (which is something that for years has done an operation with a much lower impact) will accidentally engage this feature that breaks my computer. I have to logout and log back in again. I try to resume what I was doing before, but the same thing happens again. This seems to be fairly easy to reproduce. I uninstall Nautilus and start looking at Caja. The UI isn't as smooth, but at least it works properly. It seems that there are at least 3 or 4 bugs here, most of them against nautilus: - the new search feature will almost certainly never be appropriate for certain types of remote filesystems, sftp included. It will never be possible to implement this in a way that doesn't pound hundreds or (easily) thousands of requests over the network. Unless you are on an extremely good network connection, it's going to take quite some time to clear all of these requests. - there is no way to disable the new search feature, even if only for some backends where it will never be usable - gvfs's sftp backend doesn't seem to stand up particularly well to the pounding that the search feature gives it - nautilus freezes on startup if gvfs's sftp backend won't talk to it. It should probably be more robust against this sort of problem.
Perhaps search should not be recursive by default for network places, like thumbnailing.
I do observe the same behavior for smb. I can not report any exact steps to reproduce those crashes but they happen frequently. But there seems to be a similar bug that can be reproduced quite reliably: Use a network share and type something like "abc" and then press escape immediately. I usually takes some seconds until Nautilus is usable again. Sometimes it never comes back.
3.14 is over - move to the 3.16 target milestone.
->3.18 with the search work we are planning and improvement on networks locations with the gsoc work on the network&drives view.
Is there a way to disable the recursive searching?
(In reply to obadz from comment #5) > Is there a way to disable the recursive searching? If you have to manually disable recursive search, we've already failed. I'd like to see testing to see what the bottlenecks are, as well as how/when issues present themselves. I'd also like to see us identify anything we can do to make search faster in these situations, as well as making it more tolerant to the cases described. Once that has happened, it would be interesting to look into how search behaviour can automatically compensate for the factors that may affect it on remote filesystems. This could involve limiting the depth of searches, or disabling recursive searching altogether. Other ideas would be welcome.
(In reply to Allan Day from comment #6) > (In reply to obadz from comment #5) > > Is there a way to disable the recursive searching? > > If you have to manually disable recursive search, we've already failed. True. Nevertheless, there _is_ gsettings set org.gnome.nautilus.preferences enable-recursive-search false
Created attachment 310445 [details] [review] search: don't search recursively on network locations It's too slow to search recursively on locations that are on the network. For that case, just search in the current folder.
Created attachment 310446 [details] [review] files-view: add feedback when searching on remote Last commit disable recursive search on remote locations and instead just searchs on the current directory. However, we need a way to show feedback about it to the user. Add an action bar under the view to display a label warning the user about no using recursive search.
Created attachment 310447 [details] [review] files-view: add feedback when searching on remote Last commit disable recursive search on remote locations and instead just searchs on the current directory. However, we need a way to show feedback about it to the user. Add an action bar under the view to display a label warning the user about no using recursive search.
waiting for UI freeze for the last patch. If UI freeze is not granted, I will commit the first patch which disables the recursive search anyway if nothing is against.
Created attachment 310448 [details] [review] files-view: add feedback when searching on remote Last commit disable recursive search on remote locations and instead just searchs on the current directory. However, we need a way to show feedback about it to the user. Add an action bar under the view to display a label warning the user about no using recursive search.
UI freeze and string freeze accepted. Attachment 310445 [details] pushed as d3e1a71 - search: don't search recursively on network locations Attachment 310448 [details] pushed as 23edde1 - files-view: add feedback when searching on remote
I think the third bug that Ryan is referring to in the original report is due to: commit fcffe33ba57f968e2cb0073cb201007808155702 Author: Ross Lagerwall <rosslagerwall@gmail.com> Date: Sat Sep 13 12:00:15 2014 +0100 Allow cancelling jobs that have sent a reply but not finished A few job types (mount, unmount and enumerate) can be in a state where sent_reply is TRUE but finished is FALSE because they override send_reply. If the peer connection closes during this period, the daemon hangs in peer_connection_closed because the job still exists but cannot be cancelled. To fix this, allow cancelling jobs that have sent a reply but not yet finished. This can be reproduced fairly easily by doing a search on an sftp mount in Nautilus. https://bugzilla.gnome.org/show_bug.cgi?id=720860 which was fixed a couple of cycles back. My own testing of a 3.16 Nautilus with gvfs from master shows that it functions OK (without hanging, etc), and is quite snappy over a LAN connection. That said, recursive search of a remote share is probably a bad idea.