Re: VFS integration with kernel mounts

[Alexander Larsson <alexl redhat com>]

On Thu, 2007-05-03 at 09:27 -0500, Jerry Haltom wrote:
> Sure, but that hasn't helped the user any. He still has to remember
> where he mounted a remote machine, and do the mounting manually. What
> I'm talking about would be a GVFS schema for cifs:// that would actually
> create a kernel mount. Or nfs://.

But the user can't mount a kernel mount. Only root can do that. In fact,
this is one of the primary reasons we're creating a user space vfs. So
that any user can create a cifs mount on any platform without being
root.

> > > What about auto mounting things such as USB devices? Are we going to
> > > have an abstraction around those, where you could refer to device by
> > > uuid or something?
> > > 
> > > `uuid-of-device://path/to/file`
> > > 
> > > Or are we simply going to consider it `file:///media/usbdisk-1/` and
> > > stuff like we do now? I really like the abstraction idea. It would
> > > basically be a GVFS mountable that just did whatever pmount work was
> > > necessary to get the device mounted, the proxy to the kernel VFS.
> > 
> > I haven't planned anything like this. There is an abstraction similar to
> > gnome-volume-monitor for enumerating the devices, but once they are
> > mounted we refer to them as in the filesystem. 
> 
> Again, hasn't helped the user any. He can't record these paths in recent
> files, because the mount point could change between usages or machines.
> One day usbdisk could be usbdisk-1, the next it could be usbdisk-2.

Sure, paths have problems. But your made up uuid uri has problems too.
Like aliasing, or the risk of non-unique uuids and other fragility
problems.

> > Not sure what you mean. gvfs backends can support mount on demand if
> > that is what you want. But fuse mounts are not really different than any
> > other kind of mounted filesystem, what special needs do you have?
> 
> The only need I'm talking about is hiding the actual POSIX location of
> the mount from the user. If the user is talking about flickerfs, he
> should be able to refer to it as flickerfs://, and not have to refer to
> it as file:///mnt/myflicker/.

In general the user shouldn't have to type uris at all. If a flickerfs
is mounted it should be there in the ui, clickable. And anyway, we won't
mount the flickerfs system like that. It will be a user-level mount that
is accessed through gvfs and addressed using URIs.
 
> > I'm not sure what you mean, generally file: uris map to POSIX paths, and
> > no other do.
> 
> But wouldn't you want to be able to provide a map to POSIX paths for
> *all* GVFS urls? For sftp://, smb:// and all the others. There has been
> talk on this thread about creating a ~/.local/mounts/ Fuse directory
> which would allow non-GVFS enabled programs to use GVFS files. How
> should a GVFS enabled program go about translating a GFile to this path?
> Hence the `posix-path` property. For `file:///foo/bar` it would return
> `/foo/bar`. For `smb://host/foo/bar` it might return
> `~/.local/mounts/smb;whatever;whatever/foo/bar`. Hence you can simply
> ask a GFile instance for it's POSIX path, and get one.

The g_file_get_path() is meant to return the fuse path in case of a
non-native GFile when there is fuse support. This works exactly like you
say above. It is possible to make it point to other locations than
~/.mounts/ if we make uri schemes that just alias part of the unix tree,
but as i said in my reply to davidz, I think that is very risky to do.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a benighted coffee-fuelled librarian haunted by memories of 'Nam. She's a 
pregnant French-Canadian archaeologist who believes she is the reincarnation 
of an ancient Egyptian queen. They fight crime!