Re: VFS integration with kernel mounts

[Jerry Haltom <wasabi larvalstage net>]

I believe I understand all of your points then. I'm mostly just
interested in providing something "useful" to application developers so
they can develop applications that are more "useful" to users.

Persistent bookmarks to removable devices. I think a lot of people would
like to solve this.

The ability for those bookmarks to prompt you to insert the proper
media, and if you are unable to, fail gracefully in the application. I
think this adds polish.

I do recognize of course that what we are talking about are actually
just module implementations on the core of GVFS. If *I* wanted to come
up with a media://uuid/ schema, I certainly could. Nevertheless, I want
to solicit input from the major parties involved.

Why doesn't HAL use UUIDs? I'd say probably because up until now there
was no abstraction to turn those UUIDs into usefully understandable
paths for the user. If you plug in a USB disk and open Nautilus, you see
the /media/usbdisk-1 path. They needed to make that look right and
didn't want to write a next generation VFS system like you are doing. I
could be wrong however.

It's worth noting that OS X doesn't mount with UUIDs either. They
generate a session-unique value for the mount point, which looks
resonable. They encapsulate access to this mount point in an API which
understands the uniqueness of a device.

I'd like to point out that I'm not advocating UUIDs at all, actually.
I'm advocating an abstraction for mounting and browsing removable
devices which correspond to kernel VFS paths. It just so happens UUIDs
are the first thing that came to mind. The GVFS idea of explicitly
"mounting" a resource offers us an extremely good place to add such UI
hooks. We've never had these before. There was no real good way to auto
mount kernel VFS paths, and allow the UI to request media, so it's never
been possible.

Are GFile instances extensible? Can a writer of a GVFS module cause
custom URI prefixes to return custom GFile implementations? That is
really the only thing standing in the way of such an idea being
implemented by me or others. To test out my idea, I would need to return
a GLocalAndDaemonFile instance which could return NOT_MOUNTED when it
wasn't mounted. Can I implement both mounting and local file access
through a single GFile subtype? Or do GDaemonFiles *only* support
mounting (mounting requiring communication with a daemon of some sort?)
I think this is the only area where GVFS design decisions could
potentially effect implementing this. As long as you can have a GFile
which does both local access and manages mounting, we're good.

On Fri, 2007-05-04 at 09:59 +0200, Alexander Larsson wrote:
> On Thu, 2007-05-03 at 10:18 -0500, Jerry Haltom wrote:
> > > The selection of whether to do local or remote i/o is done when
> > > instantiating the GFile. We instantiate a GLocalFile or a GDaemonFile
> > > depending on the uri and the default GVfs instance loaded. However, the
> > > mapping from URI to what should be done with the file must be done by
> > > purely in-process non-blocking simple code. Anything complicated (and
> > > asking hal over dbus for a list of uuids and their paths is very
> > > complicated) will make the GFile API totally unsuitable for what
> > > applications normally do with it. (They will block all over the place in
> > > unexpected places and generally be very slow.)
> > 
> > If this is the case then you are saying that GFiles can simply refer to
> > non existing resources, and only create IPC when the application
> > attempts to use them? This seems reasonable.
> 
> Sure, like a pathname or a uri can point to whatever. I guess there is a
> slight difference in that a GFile can't be not-well-formed. I.E. if you
> got a non-null GFile then it was a valid uri. There is also some level
> of uri canonicalization in the GFile (for instance wrt escaping).
> 
> The implemenation of GFile is either
> GLocalFile: just a pathname
> or 
> GDaemonFile: The uri is turned into a "mount specification", selecting
> what gvfs mountpoint to use as root, plus a pathname to use relative to
> that mountpoint.
> 
> The actual mapping of the "mount specification" to the entity on the
> dbus handling such mounts are done when the actual i/o operation
> happens. (And at that point you can get a not-mounted error.)
> 
> > At what stage is "mounting" considered? Translating a uri to a GFile
> > doesn't "mount" anything, does it? I would say the HAL communication
> > would occur when "mounting" the media path. Mounting seems like an
> > explicitly blocking operation.
> 
> Mounting is in almost all cases an explicit operation. I.E. you call
> some form of "mount" operation. There are a few cases where we do
> support automatic mounting on first i/o, like e.g. mounting computer://,
> but that should never happen if the mountpoint ever needs
> authentication, can fail, or if its "costly", because applications don't
> really expect such behaviour. All mount operations in gvfs are
> explicitly async, so that they can do authentication nicely and
> integrate well with a gui like gtk+.
> 
> The canonical example where automounting causes trouble is listing a
> bunch of remote locations in the nautilus sidebar. You don't want to
> open 20 authentication dialogs the first time you open the window
> because nautilus wanted to stat the locations in the sidebar to get the
> icon for them. [Although there are other problems too, see my old mail
> about the stateless of gnome-vfs being a problem.]
> 
> This might sound a bit tricky for the apps to handle perhaps, but in
> practice almost all handling of mounting will be handled by the file
> manager and the file selector, similar to how unix mounts are mainly
> ignored by apps.
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander Larsson                                            Red Hat, Inc 
>                    alexl redhat com    alla lysator liu se 
> He's a gun-slinging Catholic grifter fleeing from a secret government 
> programme. She's a virginal French-Canadian research scientist from the wrong 
> side of the tracks. They fight crime! 
>