Re: GVfs status report

[Alexander Larsson <alexl redhat com>]

On Sat, 2007-09-08 at 09:15 +1000, tpgww onepost net wrote:
> Hello all
> 
> I've been thinking about a file-manager interface to gvfs (more
> particularly, gio) to help flush out any "devil-in-detail" issues at
> this  stage of gvfs development. Found some, of course. Some are
> matters that might have an impact on gvfs design, others are just
> things for which (sans API docs) I'd welcome some explanation.
> 
> And Alex, you did request, so, here goes.
> 
> You mention that that the API is close to final now. What will happen
> to non-superseded bits of gnome-vfs? I'm thinking of things like the
> URI management functions, maybe the mime-management ones. Glib ?

Most of the stuff you mention is in gio already, like mime types,
application mapping, etc. Some things are not, mostly things no apps
use. But there are some things that we might have to move to somewhere
else. The one thing i can think of is configuration of uri-handlers like
mailto: (due to it using gconf). 

> Will the the gnome-vfs approach to "compound" URI's (IMHO "fragmented
> URI" doesn't sound too good) be retained?

No. That never worked very well, nor is it imho a good user interface
for this. I think opening file-roller is better.

> I presume that gvfs mountpoints are the respective namespace roots,
> i.e. a point does not include any initially-opened path there.

I'm not sure what you mean here. But this area is sort of complicated.
For some things like smb and ftp things are simple. The mount is in the
root of the share. However, for e.g. nfs things are complex, as the
"mountpoint" is not obvious. Take for example the /mnt/exports/foo/bar
nfs mountpoint. What is the root of that? That depends on the server
side setting. This is handled by special casing the mount prefix in the
code handling mounts. I.e. the user would specify
nfs://server/mnt/exports/foo/bar, and the code knows when listing the
mounts what the actual mountpoint is.

> Has it been resolved whether and how mountpoints would be represented
> in the native fs namespace ?

There has been no more discussions on this, and I'm not sure what the
current fuse daemon does (hpj did that). My viewpoint is that it should
use some readable "mostly unique" freeform name.

> What will a mountpoint, in ~/.mounts or whereever, look like to
> anything that doesn't know what it really is? What would happen upon
> e.g. `ls mountpoint` ? What would happen if a virtual item is
> overwritten by a native file, or an additional native file is copied
> to some path in a mountpoint ?

~/.mounts just looks like a directory with directories in it. Writes to
it will get access denied errors.

I'm not sure what you mean by native vs virtual here? They are all
"native". Pretend that all the subdirs of ~/.mounts were normal NFS
mounts and it will behave something like that.

> Is it correct that a complex mountpoint will be [un]mounted via a
> single request, so apps don't need to separately request each item in
> the chain of points?

What do you mean by this?

> There are two sorts of gvfs mount functions ATM. I'm guessing that one
> sort is for media that need to be physically [un]mounted, and probably
> this applies only to local devices/media. The other sort, I suppose,
> is for logical mounting of remote sites, archives etc. There does not
> seem to be an unmount API for the latter type - do we never expect to
> unmount them?

There are various things going on here:
First there is g_mount_for_location(). You can use this to mount the
root item for a given uri. This is useful for apps that need to access
it or for the system to mount stuff on login.

Secondly there is g_file_mount_mountable() and
g_file_unmount_mountable(). These let you mount and unmount "mountable"
file objects that you stumble upon in the filesystem. An example of this
is when looking at the list of shares in a smb server. The files in that
directory are not subdirs but file of type mountable, that you can
mount.

Third, there is a GVolume abstraction that lets you list the volumes
mounted on the system. These are things like mounted cds, or usb disks,
but also includes mounted gvfs shares like a smb or ftp share. These can
be enumerated, monitored and unmounted.

What is missing is a sort of "unmount from this uri" function, but I'm
not sure that is useful.

> A while back there was some discussion about a per-user? file, in
> effect a virtual fstab for gvfs mountpoints. Would that be stateful in
> the sense of replicating mtab as well ? How would passwords be
> managed ?

I know that nf2 scheinwelt at is working on something like that for
fuse. Its independent from gvfs, and I haven't looked at it in detail.

For passwords, well, when executing a mount you pass in a
GMountOperation object where you get callbacks when things like
passwords or answers to other questions are required. This can use
gnome-keyring, and I think we should have some standardized code in Gtk+
that you can use for this.

> Presuming that unmounting will be appropriate sometimes, and that
> different apps or instances of same app might independently mount and
> unmount, is there a ref counting process for mountpoints ?

No.

> What encoding should be used for paths and names in gvfs mountpoints ?
> e.g. an archive could have been created anywhere.
> Should there be a point-specific encoding property that can be
> interrogated by an app, or should apps manage such encoding
> themselves ?
> What encoding for strings e.g. default user in mount-related
> callbacks ?

Paths are byte strings and have no enforced encoding. However, for
filename display and to handle e.g. rename from an inputed utf8 filename
there is handling of "display names" and "edit name" in the gio api. For
gvfs internally each mountpoint has an encoding used for this. 

> A couple of mount-related callbacks have no user-data parameter, it
> would be friendly to provide that instead of the app having to set/get
> data in order to interface with mount-related data.

Which do you refer to? The GMountOperation signals? These get the
GMountOperation which is an derived object you yourself handed it, which
is useable as a user data.

> What happens when some relevant daemon goes AWOL ? Will gio operations
> simply (hopefully not silently) fail ?

The mountpoint will be forcefully unmounted, and i/o operations will get
errors like reading from an unmounted share. Maybe we want to have part
of the desktop watch for this and throw up a warning dialog.

> There's a flag for traversing [or not] links when getting or setting
> properties of a GFile. I don't see the same thing for checking whether
> it's possible to set properties.

g_file_query_settable_attributes() is really a per-mount kind of thing.
So, it lists the type of properties the backend supports, not what is
guaranteed to succeed at setting for that particular file. For instace,
it will return that you can set the mtime for all local files, but
permissions, acls, readonly-mounts etc are all things that can cause the
actual property set to fail. Thus, I don't think following symlinks
matter here.

> Do apps _really_ need to use string-form property names for getting
> and setting properties ? Seems clunky in userland. The lib could
> translate between string and something shorter, if strings are needed
> for daemon communication ?

Its used so that it is extensible. What other approach is there?
Hardcoding in gio all the possible properties? How would you then handle
things like extended attributes, custom webdav attributes, or just
backend specific attributes that are not in gio.

> If an app requests a property in a form other than which it's stored
> (i.e. an integer of a different size) does the request fail, or is it
> simply cast before return ?

Thats not quite how it works. You get the property using
g_file_get_info(). This gets you a GFileInfo object where you can read
both the type and the value.  (You can of course try to read with the
wrong type from the GFileInfo, this fails.)

> Is it correct that the generic approach for renaming is to change name
> property, i.e. not a NIXish move. 

Sort of, use the g_file_set_display_name() operation. Move exists, but
in some backends that can result in a copy+delete operation.

> Can ACL's and other extended attributes be checked and set ?

Yes. The GFileInfo attribute system is very extensible.

> In the same vein as the test for modifiable properties of an item, it
> might sometimes be desirable to check operation validity (e.g. does
> this method support deletion), as an alternative to just trying and
> failing. I'm thinking of a case where alternative handlers are
> pre-assigned to operations. Not very likely, I guess.

Hmmm, there are some attributes that are related to this:

#define G_FILE_ATTRIBUTE_ACCESS_CAN_READ "access:can_read"       /* boolean */
#define G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE "access:can_write"     /* boolean */
#define G_FILE_ATTRIBUTE_ACCESS_CAN_EXECUTE "access:can_execute" /* boolean */
#define G_FILE_ATTRIBUTE_ACCESS_CAN_DELETE "access:can_delete"   /* boolean */
#define G_FILE_ATTRIBUTE_ACCESS_CAN_RENAME "access:can_rename"   /* boolean */ 

These are generally set depending on the (backend-dependent) permissions
of the file. While this is non-ideal from a batched run point of view
(its racy, everyone will tell you to just check the error) it is very
useful to gray out the menu items in a file manager to avoid the user
seeing spurios errors. I guess a backend that didn't support delete
could set these.

> Is file- and directory-change-monitoring only for native items ATM? If
> so, what's the outlook for this changing ?

At the moment, yes. I don't know any other backend that allows me to
implement change monioring atm. The SMB protocol supports it, but not
libsmbclient. From an API point of view its already supported though
(i.e. only backend code additions would be needed).

Actually, there is a polling fallback for the file change monitor, and
that will work for non-native files too. But the above is true for
directory monitoring and "native" non-polling file monitoring.