Re: VFS integration with kernel mounts

[Jerry Haltom <wasabi larvalstage net>]

On Wed, 2007-05-02 at 14:55 +0200, Alexander Larsson wrote:
> On Tue, 2007-05-01 at 22:34 -0500, Jerry Haltom wrote:
> > I've been reading back in the discussion this February, about GVFS and
> > Alex's design and such. Read the postings about legacy VFS integration
> > and creating a Fuse mount point into GVFS at ~/.mount or similar. I find
> > that really interesting.
> > 
> > What about the reverse? Are we going to use file:/// to access NFS
> > directories and in-kernel CIFS mounts? Or is an abstraction going to be
> > provided around these where appropriate? Or are we simply going to not
> > touch on the problem?
> 
> I'm not sure what you mean. Access to such files would be through the
> GFile apis, and will result in normal posix calls.

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

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

> > Then what about arbitrary FUSE file systems? Is it an acceptable
> > solution to write a fuse GVFS backend which auto-mounts?
> 
> 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/.

> > How should the translation from GVFS URI to POSIX path be handled? A
> > `posix-path` property on a GFile? It should mount in ~/.mount if it was
> > a pure-GVFS file system, or return the real underlying kernel path if
> > it's just wrapped?
> 
> 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.