Re: [RFC] gvfs connected servers

[David Zeuthen <david fubar dk>]

On Mon, 2008-10-06 at 19:48 +0200, Alexander Larsson wrote:
> >  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.

I agree; I think multiple icons are desirable.

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

Actually we _need_ to support mounts inside mounts happening; for
example consider

 /mnt/usbdisk1
 /mnt/usbdisk1/usbdisk2

Sure, it's a _really_ contrived example but keep in mind it's perfectly
legal... the user can easily make this happen by doing

 # mkdir /mnt/usbdisk1
 # mount /dev/sdb1 /mnt/usbdisk1
 # mkdir /mnt/usbdisk2
 # mount /dev/sdb2 /mnt/usbdisk1/usbdisk2

with /dev/sdb1, /dev/sdb2 being two mountable partitions on a USB thumb
drive.

> In fact, the whole uri to mount/mountspec system would fail. So I'm
> pretty sure this would be a bad idea. 

Is this fixable? Seems to me it should be fixable without changing
public API...

> That brings us back to multiple
> volumes per mount then I guess. I'll have a look at your patches
> tomorrow.

I'm actually pretty close to finishing a patchset for shadow mounts [1],
e.g. the in-process proxy volume monitor will automagically create and
remove GProxyShadowMount's for volumes with an activation_uri according
to if there's a real mount for the activation_uri. E.g. we'll get

 GProxyVolume ("Home dir on quad.local") - proxies GConnectedServerVolume
  GProxyShadowMount (root: sftp://quad.local/home/davidz)

 GProxyVolume ("Movies on quad.local") - proxies GConnectedServerVolume
  GProxyShadowMount (root: sftp://quad.local/media/Movies)

 GProxyVolume ("2GB USB Disk") - proxies GHalVolume
  GProxyMount (root: file:///media/usbdisk) - proxies GHalMount

 GDaemonMount (root: sftp://quad.local/)

It's a bit magic in the sense that we really need the shadow mounts to
be in-process so it's easy to forward method calls on GProxyShadowMount
(unmounting etc.) to e.g. GDaemonMount. Hence, it's somewhat different
from the usual GProxyMount class (included in the tree above just for
illustration purposes) that proxies stuff over D-Bus to the remote
volume monitor.

The upside is that this is exactly what we need for other users of the
adoption API; e.g. the gphoto2 and cdda backends; pretty much the same
functionality is needed....

Anyway, I'll try to finish that patchset... even if we end up deciding
going for the shared mount model.

      David

[1] : ... if you have a better name, I'm all ears! It's not like my
history shows I'm good at naming stuff ;-)