On Thu, 2007-05-03 at 00:50 -0400, David Zeuthen wrote:
> Or maybe I'm missing something? Feel free to tell me to read docs and/or
> the code if my question is stupid and the answer already lies there.
> Thanks!
Its true that there is a form of mapping going on with the fuse layer.
Here is how it works:
There is a set of currently mounted gvfs objects. We run an app that
enumerates these and follow changes to this list, we then expose each of
these using fuse as a directory in (e.g.) ~/.mounts. Now, normal gvfs
using apps are totally ignorant of this vfs mount <-> pathname mapping.
It is basically only used by nautilus when launching a program that
doesn't support uris. (Although a gvfs-supporting fileselector could
detect the ~/.mount prefix and reverse-map to a uri while showing the
file selector.)
The way a normal application uses gvfs is by the gio apis. Essentially
you hand over a uri, and this uri is parsed by custom uri-type specific
code into a mount specification (info about a gvfs mountpoint) and a
path into it. Each operation on this mount is sent to the right mount
daemon for the particular mount, and if its not running it will just
give a NOT_MOUNTED error.
Its conceivable to have a gvfs mount type that just "proxies" operations
from a uri to a mounted filesystem. Say you'd map media://UUID/path to
the mountspec type=media;uid=UUID. Then we automount mountpoints for all
currently mounted media. An access to such a mounted media would work,
although slowly, as all operations would go through an extra daemon via
dbus. Access via the fuse layer would work too, but go through even more
layers. In the case when the media was not mounted one would get
NOT_MOUNTED errors from gvfs. These errors are normally handled by the
file manager or the file selector and can try to mount the location,
showing a dialog which could incorporate "Please insert volume <foo>"
dialogs.
Its also possible to modify the uri-to-fuse-path code to map such mounts
to their "actual" location. Although you can't do the reverse mapping in
this case (since that has to be a fast and i/o free operation).
Will it work. I guess, yes. However, it will be slower for gvfs apps,
and I still think the aliasing is gonna be confusing. I.E there will be
two visible locations that map to the same place. Code will look at a
particular location name and don't expect things like a delete in this
place will also delete in some other place (like say the source location
of the copy you were doing). We do already have aliasing problems in the
fuse case, but there the alias is in a hidden location, only used by
non-native applications as a fallback.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
[EMAIL PROTECTED] [EMAIL PROTECTED]
He's a short-sighted alcoholic ex-con gone bad. She's a man-hating blonde
mermaid on her way to prison for a murder she didn't commit. They fight crime!
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
