Re: VFS for legacy apps (was: gvfs status report)

[Jerome Haltom <wasabi larvalstage net>]

On Thu, 2007-02-22 at 17:39 -0500, Sean Middleditch wrote:
> Just a reminder that : is the separator used in the PATH environment
> variable, and is thus a poor choice for use in directories.
> 
> In all honesty, if the intended use case for reading the directory info
> is for FUSE and GVFS, I think it would be a lot cleaner to just put some
> kind of user-friendly name in ~/.mounts/, and then create a ~/.mountrc
> config file that maps the names to mount parameters which the FUSE fs
> and GVFS can use to recreate the mount points.  Basically, it'd just be
> a per-user fstab replacement.

I want to make sure this takes NFS mounted home directories into
consideration. I think perhaps ~ is a very poor choice of location for
this.

> 
> Add in a few CLI utils to call mount with the right parameters for
> mounts in ~/.mountrc, and you'll have a pretty solid system for both
> modern GUI, legacy GUI, and CLI users.
> 
> >> You're probably always going to need type, server and share though, so
> >> maybe you can make it a bit more readable:
> >> 
> >>   ~/.mounts/smb:$server:$share/dir/file.txt
> >> 
> >> Extra options can go on the end.
> >> 
> >> Also I'd probably avoid ';' just in case bash goes anywhere near it.
> >
> > Sure, those are requred. But say we have two optional things, like user
> > and domain, as in smb:server:share:user:domain. But what do we then do
> > if user is unset, but domain isn't. I guess one could do
> > smb:server:share::domain. Still, it requires very specific handling of
> > each type of share with a specified option order etc. A key=value
> > approach is more generic.