Re: VFS for legacy apps (was: gvfs status report)
- From: Sean Middleditch <elanthis awesomeplay com>
- To: Alexander Larsson <alexl redhat com>
- Cc: gnome-vfs-list gnome org <gnome-vfs-list gnome org>, gtk-devel-list gnome org <gtk-devel-list gnome org>
- Subject: Re: VFS for legacy apps (was: gvfs status report)
- Date: Thu, 22 Feb 2007 17:39:15 -0500
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.
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.
--
Sean Middleditch <elanthis awesomeplay com>
[
Date Prev][
Date Next] [
Thread Prev][Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]