Re: VFS integration with kernel mounts

[Jerry Haltom <wasabi larvalstage net>]

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