GNOME Bugzilla – Bug 522140
nautilus does not show existing connected servers
Last modified: 2013-02-05 16:43:43 UTC
Please describe the problem: in gnome/nautilus 2.20 I had about 8 SFTP (ssh) servers connected using nautilus (using the Places>Connect to server feature of gnome panel). These shares appeared on my desktop and in network:/// I am now running hardy with nautilus 2.21.92, and my "connected shares" are all gone. I can't access them, even though they are still present in gconf (/desktop/gnome/connected_servers). So, they don't show up on the desktop, in the Network "place", or in the "Places" menu. Steps to reproduce: 1. try connecting to sftp://me@somehost/some/folder Actual results: I get no errors, but "me on somehost" appears on the desktop automatically for the duration of the gnome session. However, there is no more way for me to "mount" that some/folder remote place like I did in gnome 2.20. It seems that it is expected that the user uses generic bookmarks. Wtf? bookmarking works. The problem is that I find this to be suboptimal. There are two issues involved: - the "I can't use the old server connection dialog" currently, which is Bug #520390 - the duplication of folders and the use of bookmarks* The current workflow in 2.22 is this: - mount: sftp on kirika - bookmark: folder1 on sftp on kirika - bookmark: folder2 on sftp on kirika Expected results: My previous workflow, in gnome 2.20, was this: - mount: folder1 on sftp on kirika - mount: folder2 on sftp on kirika So, I don't want to have unnecessary "/" mounts that I will never use. I want only mounts that point to specific folders. I think this is a much superior technique desktop-clutter-wise. So, in short: please bring me my 2.20 behavior back? Does this happen every time? Yes Other information: Initially filed as https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/198857
I agree that there's a big flaw in the current behaviour. 1) Sometimes, you not have read access on "/" of a distant host 2) You don't want to display on the desktop something you will never use. (a direct connection to the "/" is rarely needed). Let's take one example : I've mounted a SFTP distant folder on my mother's desktop so she can easily upload pictures on his blog. It works great. If it's decided that such things should go in the bookmarks, I might accept this and learn her to use the bookmarks instead of the folders on her desktop(*). But why oh why should she have an icon on her desktop pointing to something she doesn't understand (the "/" folder of an hosting server is not something she can understand). (*) Although I must say that such a change in user habits must be higly motivated. The UI has not to depend of the implementational stuff behing. The GVFS thing is something my mother doesn't car and doesn't have to care. I have to explain here the logic behind her UI change, like "Using bookmarks is more consistent with the rest of the desktop"(which I don't believe) or whatever. Also, the use of bookmarks breaks completely my current spatial nautilus workflow where all I do start on the desktop. Providing a way to display bookmarks on the desktop might be a (naughty) workaround but I must agree that this I'm not the general use case so it's more of a sidesnote. Anyway, in order to solve this bug, I consider that : - Mounted / must never be showed anywhere. It must be transparent. - The current "connect" dialog has to create a bookmark automatically (and mount the server if not already) Optional : Networked bookmarks must be shown on the desktop (to provide backward compatibility with the current experience) Optional : Currently saved network places must be automatically imported into bookmarks.
Unfortunately, this is a regression. We hope to fix it for GNOME 2.24. This also requires GVFS changes: a volume monitor handling remote locations. We are also discussing a concept of "default locations", which will open your remote $HOME when opening a volume corresponding to a remote server. Confirming.
Any plans of backporting the fix or part of it to the 2.22 series by any chance?
> Any plans of backporting the fix or part of it to the 2.22 series by any chance? Unfortunately our development rules do not allow this. For instance, adding new user interface components to stable releases is not possible. http://live.gnome.org/ReleasePlanning/Freezes has some more info on it.
bump, any news on this front? I don't think this was solved in 2.24 (from what I could see in my limited testing), so could this be looked upon for 2.26? I'm pretty sure that quite a lot of people have been waiting on this to be fixed, and using "launchers" that point to sftp://foo@bar/baz (which newcomers may certainly not think of?) seems like a terrible hack to me. Especially since it creates a "useless" temporary mount (not even to the right folder) on the desktop, to make things more confusing.
I'm wondering if this could be recrafted/redesigned differently for gnome 3.0, using a better concept for favorite places in the activity pane?
Mass component change due to BZ cleanup, sorry for the noise.
Is this still an issue?
Given that the desktop is dead and that Nautilus 3.6's bookmarking feature seems to work as I expect it to nowadays, I'll put this bug report out of its misery.