Re: VFS integration with kernel mounts

[Alexander Larsson <alexl redhat com>]

On Thu, 2007-05-03 at 09:38 -0500, Jerry Haltom wrote:
> > Will it work. I guess, yes. However, it will be slower for gvfs apps,
> > and I still think the aliasing is gonna be confusing. I.E there will be
> > two visible locations that map to the same place. Code will look at a
> > particular location name and don't expect things like a delete in this
> > place will also delete in some other place (like say the source location
> > of the copy you were doing). We do already have aliasing problems in the
> > fuse case, but there the alias is in a hidden location, only used by
> > non-native applications as a fallback.
> 
> I don't really understand why it would have to be slower. Lets say you
> have a gio aware application, it is accessing `file:///foo/bar`.  How
> does the mount for file know to not talk to a daemon? How does it know
> to actually just do regular io against `/foo/bar`. The answer to this is
> the same as the answer to the question about how `media-uuid://foo/bar`
> knows to use real POSIX io to `/media/usbdisk-1/foo/bar`.
> 
> At some point, in the gio consuming application, a decision has to be
> made about whether the io can be done locally, should be done locally,
> or should be done through a daemon. For file: this decision is obvious.
> It should always be done in process. For http: it should be done out of
> process. For media-uuid: it should be done in process, but during the
> "mounting" stage something has to make sure the volume is actually
> present and mounted by the kernel.
> 
> All of these paths should be translatable into a posix-safe path for non
> gio-aware applications, either by returning the real underlying path, or
> by returning a path to a fuse mounted file system into gio.

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

One of the defining aspects of the GFile object is that its a
light-weight client side only reference to a file. In all aspects an
abstraction of a filename string.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a hate-fuelled Jewish filmmaker with a passion for fast cars. She's a 
bloodthirsty wisecracking journalist living homeless in New York's sewers. 
They fight crime!