On Sat, 2007-09-08 at 09:15 +1000, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. _______________________________________________ gnome-vfs-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
