Re: gvfs status report

[Alexander Larsson <alexl redhat com>]

On Mon, 2007-02-19 at 18:04 -0600, Hans Petter Jansson wrote:
> On Thu, 2007-02-15 at 16:54 +0100, Alexander Larsson wrote:
> > A large problem with gnome-vfs is that applications not specially
> > coded to use gnome-vfs will not be able to read non-local files. A
> > nice solution to this would be to use FUSE to let such apps use normal
> > syscalls to access the files. In general its quite tricky to map any
> > URI to a FUSE file, but with the mountpoint + filename setup gvfs uses
> > it is very easy to create a FUSE filesystem that lets you access all
> > the current vfs mounts. 
> 
> Could we standardize the local file system paths for non-gvfs apps, so
> we can reliably DnD to them and have them receive local paths? E.g.
> 
> ~/.mounts/<protocol>/<server>/<path>
> 
> Consider also apps that receive these local paths, store them and
> reference them in future sessions.
> 
> I think it would be wise to include such functionality, or at least
> specifications, if we're going to replace gnome-vfs anyway. It would
> save worlds of pain in scenarios involving legacy or 3rd party apps.
> 
> Having these paths map 1:1 to URIs (with translation functions?) would
> be excellent. It seems you've given it some thought - what are the
> tricky parts?

Its in general very tricky to use non-path properties from the
mountpoint as a path. I tried really hard to get it in some sane
fashion, but didn't succeed. The main problem is that there is a lot of
optional things, but paths don't allow that.

Lets take smb for example. It sounds so simple to just go with
~/.mounts/smb-share/$server/$share/dir/file.txt. However, the devil is
in the details. What if you specify a different port? a different user?
a different domain? For the case where user is specified you might get
~/.mounts/smb-share/$server/$share/$user/dir/file.txt. How do you
recognize this form as opposed to the previous case, but with "dir"
being $user. 

One solution for that would be to enforce a number of path elements
enough for all the possible optional settings for the protocol type. Of
course, you can't have empty dir names, so you need a magic marker (say
"*") for that.  So, you'd get
~/.mounts/smb-share/$server/$share/$user/$domain/$port, where a typical
example would be ~/.mounts/smb-share/$server/$share/*/*/*/dir/file.txt.

Not only is this extraordinary ugly, it also have various problems. For
instance, what is in these directories? What happens if you try to
rename the "*" to something else. How do we add options to a mountpoint
type after we've deployed with some max number of options? Also, things
get slightly tricky when parts of the prefix are shared between
different mounts.

In general, the way mountpoints work in unix is that they are mounted
over *one* directory, and don't mix things up with other mounts, so I
think the best solution would be to have each mountpoint be one
subdirectory under ~/.mounts (or whatever). 

The question is then, how do we name these subdirectories. I've come up
with two plausible versions. One, we use the full mount specification
and encode it (with escaping) in the mountpoint name. So, you'd have 
~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt.

Two, each mountpoint generates a display name that is used in the gui
for the mountpoint. An example for smb would be "$share share at
$server". This is weakly unique[1] on the same machine. We can make it
guaranteed unique in the daemon and use this as the mountpoint name.
Like this
~/.mount/$share share at $server/dir/file.txt. 

The second method isn't really possible to map backwards to the original
source of the mountpoint if the mountpoint is not mounted. However in
almost all cases where we access a file from it, it will be mounted
already, and thus mapped in the same place. So this isn't really a
problem in practice, especially since the desktop itself natively
handles gvfs mounts. And if its not mounted you can easily display a
warning that "$share share at $server" isn't mounted which is nice and
readable. This isn't really all that different to traditional unix
mounts. For instance you can't map from a nfs mountpoint
like /mnt/bigserver to the exact nfs details of the mounpoint (if its
not mounted).

The advantage of method one is that you can actually take such a path
and extract enought information to mount the path. On the other hand, it
looks like total ass. Pray that it doesn't show up in the UI somewhere.

[1] I say weakly, because with an example like "music share at bigserver
as user alex" could conflict if you have a server called "bigserver as
user alex". In that (rare) case we can prepend a number in the daemon,
making things really unique.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's an impetuous crooked messiah whom everyone believes is mad. She's a 
radical snooty bounty hunter with only herself to blame. They fight crime!