Re: [RFC] gvfs connected servers

[Alexander Larsson <alexl redhat com>]

On Mon, 2008-10-06 at 11:36 -0400, David Zeuthen wrote:

> > Now, I don't have a perfect solution already, but lets discuss the
> > possibilities here. The other approach would be to have different mounts
> > for these two volumes. However, we want to share the backing mount
> > (ssh://quad.local/) for them both, so this isn't ideal. 
> > 
> > What if we make the mounts for these volumes "virtual", pointing to
> > their ancestor mount instead? Kinda like symlink mounts? 
> 
> I'm not sure what a symlink mount is...

Well. Its not something that currently exists. What i mean is that its a
mount that doesn't have a "real" mount as a backing. It just piggybacks
on some other mount.

> > If we did that then to the above would be added a third GVolume, for the
> > root GMount (ssh://quad.local). I think that is sane, since otherwise
> > you wouldn't have anything anchoring that mount (i.e. no volume for the
> > root location on ssh://quad.local).
> 
> But that is the situation right now; we currently don't have volumes
> anchoring any of the current sftp/smb mounts etc. Btw, unanchored mounts
> are fine; even in a world with connected servers we'd still want that
> for transient mounts you only intend to use once and disconnect. One
> use-case is that you're at a conference and connecting to a someone's
> "Public Files" DAV share to get a single file; when you have the file
> you disconnect from the machine. So we still want to support unanchored
> mounts.

Yeah.

> Hmm. I guess we could add GMount objects in the connected-server volume
> monitor; it'd look like this
> 
>  GConnectedServerVolume ("Home dir on quad.local")
>   GConnectedServerMount (root: sftp://quad.local/home/davidz)
> 
>  GConnectedServerVolume ("Movies on quad.local")
>   GConnectedServerMount (root: sftp://quad.local/media/Movies)
> 
>  GDaemonMount (root: sftp://quad.local/)

This is pretty much what I meant.

> There's at least two issues with this
> 
>  1. The file manager and file chooser would display three icons
> 
>      Home dir on quad.local
>      Movies on quad.local
>      sftp mount at quad.local
> 
>     where the last one only shows up with the former two are mounted.
>     The thing here is that we don't want "sftp mount at quad.local" to
>     be shown at all.
> 
>     We can get around that by making the file manager and the file
>     chooser not show unanchored mounts if, and only if, there exists a
>     volume with an activation root inside it.

The current code does something similar anyway. If you mount
sftp://host/ first you'll see the root mount and then you add a volume
to sftp://host/some/dir that mount will go away. Of course, the current
code needs no changes for this as it automatically falls out of the
current algorithms.

>  2. Not sure how if the various path bars (in the file manager and the
>     file chooser) would stop working; with this setup we'd have mounts
>     inside mounts, e.g.
> 
>     [[icon] sftp mount at quad.local] [home] [[icon] Home dir on quad.local]

Yeah, but is this bad? In the shared-mount model you get no icon at all
for the "home dir" volume, other than the link to the activation
location. I'd argue that this is less useful for users.

On the other hand, I can imagine various pieces of code inside gvfs
breaking when there are mounts inside mounts... So I'm not 100% sure
this is a good idea either...

In fact, the whole uri to mount/mountspec system would fail. So I'm
pretty sure this would be a bad idea. That brings us back to multiple
volumes per mount then I guess. I'll have a look at your patches
tomorrow.