gnome-vfs network servers are not migrated to gvfs on upgrade

[Jeff Fortin Tam]

Binary package hint: gvfs

I don't know if this is an
- upstream bug
- ubuntu bug

-nautilus bug
- gvfs bug

So please triage this if you have a better idea of culprit.

Basically, 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.

This is a dealbreaker for me, as I used nautilus' sftp/ftp/smb features all the time. Not having those would mean I am better of using thunar, since it's basically a faster nautilus without network capability.

So, any thoughts what might be the cause of this problem?

[Sebastien Bacher (seb128)]

the nautilus version in hardy uses the new gvfs and not gnomevfs ideally the shortcut could be migrated but that has not been done yet

[Jeff Fortin Tam (kiddo)]

what do you mean by shortcut? if I understand correctly, you mean that while gvfs supports navigating through the network, nautilus has not migrated a way to "remember" those locations to gvfs? Is it an upstream bug?

[Sebastien Bacher (seb128)]

gnomevfs was not mounted shares so the connect to server was there to have an easy way to browse the same place without having to browse to it every time, now gvfs is doing mounts when you access the share so you can simply use standard bookmarks

[Jeff Fortin Tam (kiddo)]

ok, but does that mean the previous way feature is gone, or is it planned for it to come back? Because the current behavior is HIGHLY inferior. You can't connect "certain folders from a server". Bookmarks are not a viable option.

[Jeff Fortin Tam (kiddo)]

adding some precision: bookmarks are not a viable option because
- It creates duplication (1 mount + n bookmarks)
- I want a distinction between my local stuff and "mounted" stuff

[Sebastien Bacher (seb128)]

what do you mean that you can't connect certain folders from a server? bookmarking this folder should word correctly. What do you do exactly and what error do you get?

[Jeff Fortin Tam (kiddo)]

I get no errors, 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", which is Bug #198531
- the duplication of folders and the use of bookmarks*

So here is my big question. If bug #198531 is fixed, will I be able to connect to a server, specifying a folder, and that it would be "mounted" with that folder ONLY, not "mounted at / with an additional bookmark to /foo/bar"?

As I said, using bookmarks is not very nice because
- It creates duplication (1 mount + n bookmarks)
- I want a distinction between my local stuff and "mounted" stuff

Basically, I just want to be sure that I will not be forced to have, let's say:
- mount: sftp on kirika
- bookmark: folder1 on sftp on kirika
- bookmark: folder2 on sftp on kirika

My current 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.

Does that explanation make things clearer than before?

[Sebastien Bacher (seb128)]

no, the current design doesn't allow you to do what you describe, gvfs does mount locations and those displayed. I don't think that's something we can change for hardy and that should be discussed upstream, likely not trivial to do. The solution would likely to allow to customize what is displayed

[Lionel Dricot (ploum-deactivatedaccount)]

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. Currently, the whole discussion is about wheter or not the architecture can do it. This is really bad. We cannot change the UI behaviour based on the architecture. It's the wrongest thing we can ever do in UI design.

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.

[Sebastien Bacher (seb128)]

Lionel you are commenting at the wrong place, ubuntu doesn't do the GNOME design and you should know that, we can hide the mounts icons if that's your issue though and tell users to use bookmarks there

[Lionel Dricot (ploum-deactivatedaccount)]

Sébastien : I agree, I posted it also on BGo. Anyway, even if Gnome doesn't adress this issue in the 2.22 release, I think that Ubuntu should adress this before Hardy release or, at least, that this issue should be explained carefully in the release note as it may break a lot of habits and user configurations.

[Sebastien Bacher (seb128)]

Lionel, what is so weird about having to use bookmarks? You seems to be confused about mounts on the desktop which is only a gconf key to change

[Lionel Dricot (ploum-deactivatedaccount)]

Sebastien >

a) it's weird to have mounted volume that you don't use and that you will never use ("/"). Unfortunately, changing the gconf key means that you don't have other mounted volume (USB key, CD rom). That's what I believe is really weird (and wrong from an UI perspective).

b) With the bookmarks, I've no real problem (except my spatial mode thingy but let forget it for now). It's just that being forced to use bookmarks breaks the current behavior and might change the way users use their computer. I've no specific complain against it but I believe that forcing a change is user behavior must be motivated by some reason.

I admit that b) is more something to discuss. But point a) is a real huge UI problem that must be solved before Hardy release, IMHO (considering that Hardy is a LTS).

I'm perhaps out of topic for this bug so I consider opening a new bug which could be : "Mounted volumes should not be always at root but should have a configurable default path". What do you think ?

[Lionel Dricot (ploum-deactivatedaccount)]

I've given more thought to that problem and I understand better Sébastien's position on the problem. It's clearly not an easy problem.

[Sebastien Bacher (seb128)]

You suggest than showing mounts is weird, you could argue the same about an usb key then, why displaying the key where you might only want to use one directory on it? Why displaying your vista disk where you might just use your user directory there? The current interface is coherent and treat all the locations the same way, why do you think it's weird?

Not sure what is your spatial issue, but gnomevfs has no mounts and what you added using the connect to server dialog was special bookmarks for easier access to those locations. So basically you are saying gnome-vfs bookmarks were nicer than normal bookmark? Why do you think that? What difference do you make between those exactly?

You also have wrong expectation about what a lts is, thats a version with longer support but there no engagement on having no issue there since most of the code comes from upstream and we don't have control over their changes. We try to get every ubuntu version as good as possible and this one is not an exception

[Lionel Dricot (ploum-deactivatedaccount)]

Sébastien > I think I understand your point. In order to be more constructive, I created 4 bugs that should summarize what I think :

http://bugzilla.gnome.org/show_bug.cgi?id=522917
http://bugzilla.gnome.org/show_bug.cgi?id=522918
http://bugzilla.gnome.org/show_bug.cgi?id=522920
http://bugzilla.gnome.org/show_bug.cgi?id=522922

The first one is the one I consider critical and that should be, IMHO, solved before Hardy. (not solving it would be a big usability drawback from a end-user perspective)

Thanks for your comments, it helped me to make things clear in my mind.

[Jeff Fortin Tam (kiddo)]

as I have a very bad feeling that this may not be fixed in hardy at all, could we at least have a usability workaround that prevents nautilus from showing those "temporary" network mounts on the desktop when...

1- the user chose to make a bookmark out of it with the connect dialog
2- the user accesses a "bookmarked network directory"?

[Jim Braux-Zin (j-brauxzin)]

I think there is a problem with how nautilus handles those gvfs bookmarks :

1) Open a gedit window, and navigate through remote ftps with the sidepanel : you can open and save all files as if they were on a local drive, no "mount" icon appears on the desktop.

2) Open the same ftp with nautilus : it does create a "mount" icon on the desktop.

That's weird and inconsistent but the real problem is :

3) Go back to the gedit window : you can't access the files on the mounted server anymore until you "unmount" the server.

As a side-effect : double-clicking on a remote file in nautilus opens gedit but gedit can't access the file...

[Sebastien Bacher (seb128)]

gedit still uses gnome-vfs, do you use a ftp server which limits the number of clients connected?

[Jim Braux-Zin (j-brauxzin)]

I'm almost sure the server I tested with don't limit the connections. At
least, I don't have to set up a limit it in Filezilla to make them work.

On Sun, Apr 13, 2008 at 3:08 PM, Sebastien Bacher <email address hidden> wrote:

> gedit still uses gnome-vfs, do you use a ftp server which limits the
> number of clients connected?
>
> --
> gnome-vfs network servers are not migrated to gvfs on upgrade
> https://bugs.launchpad.net/bugs/198857
> You received this bug notification because you are a direct subscriber
> of the bug.
>
>

--
Jim Braux-Zin

[Jordan Hall (jordan-hall)]

I am working for a web development company, and having my FTP connection vanishing on upgrade was an incredible usability issue.

In addition, I've now noticed my connections are no longer remembered between sessions, which again is very bad usability for my use case. I'm assuming this is a problem/design issue in gvfs and/or the way it is integrated with Nautilus.

[Jeff Fortin Tam (kiddo)]

so far, the only solution I have found to hack around the issue to a limited extent (without messing my bookmarks) is creating launchers on the desktop or panel. Screenshot attached.

[Steve Langasek (vorlon)]

No code is available yet for managing this upgrade, and there are insufficient resources to get this implemented for 8.04.1. As such, we'll have missed the window in which it makes sense to implement this, since the upgrade support won't be present when the vast majority of users are going to be upgrading. I'm therefore marking this bug 'wontfix' with regrets.