system and desktop VFS merged
spam at micropp.se
Mon Mar 28 00:41:15 EEST 2005
Sean Middleditch wrote:
>I really see no purpose in using the VFS path stuff. Classic UNIX uses
I can se a smal point. If You configure an viewer for a filebrowser
using some syntax, say "foo %u" for an app that want an uri, and "foo
%f" for an app that want an pathname. Then the filebrowser can easy
translate the uri to an path if it is avalible. That is some usefullnes
But i think the /vfs structure have problems. What if more than one user
mount ther home directory over the same protocoll from the same server?
Then we need username in the pathname.
If the D-VFS deamon keep track of mountpoints, it can provide that
translation anyvay. And any filebrowser that need do the translation
just must be D_VFS avere!
> If a user wants their legacy app to access a remote share,
>they should mount it just like they currently do with sshfs or smbfs or
>whatever. They can mount it anywhere they want - I usually mount remote
>shares in ~/.mount/ for example. If a user wants a dynamic mount area,
>I'd suggest having the individual users mount such a dynamic filesystem
>in their home folder as well.
You talk about somthing like dvfsmount that take an uri insted of an
device? I would be verry happy with that. Like that kind of controll
over what get mounted where :-)
If the D-VFS demon keep track of the maintpoint and can do uri -> path
translation it good enuf for all I can think of :-)
a smal tool for translation maybee so You can type:
$ emacs `dvfspath ssh://foo.org/bar.cc`
$ cd `dvfspath ssh://foo.org/`
And it works if ssh://foo.org/ is mounted somewher, wherever the user
Then some optional automounting featur can be added for user that want
that. I don't think I'm one of them. If the D-VFS deamon and api can
tell what conections are 'up', or even - a proc can ask to licening on
all vfs conect/disconect events thru D-BUS... Then writing such
'standalone' automounter must be simple.
More information about the xdg