On Thu, 2002-09-12 at 00:55, Christophe Fergeau wrote: > Hi, > > Currently it seems that GnomeVFSFileInfo doesn't report some very useful information : whether an URI is readable, writeable or executable. > This is quite annoying since, for example, this prevents gedit from being able to tell if it can edit a remote location or not. Nautilus has some code to try to handle that, but it probably will only work in the local case. > > What I'm suggesting is to report these permissions (ie the values returned by access(2) in the local case) in the GnomeVFSFileInfo struct. There we have 2 possibilities: add it to the permissions field, or use one of the padding pointers at the end of the struct to store them (not really a good idea to use one of those to only store 3 bits imo), and to add a new member to GnomeVFSFileInfoFields to report if the information about the authorizations is there or not. > > Does it seem sensible ? Did I miss something ? And more importantly, will a patch doing that be accepted or not ? This is definately something we want. Nautilus has this idea in its NautilusFile objects so theres even some logic there we can base it off. Seth and I have discussed putting it into GnomeVFSFileInfo, I think Seth had some particular idea about how thought it should be done, as far as I'm concerned it can just be a bitfield added to the end with another flag in the flags field to indicate its validity. This makes *much* more sense for non-local filesystems (when uid/gid/perms makes no sense) and also answers the kind of questions that applications want to ask. On a tangent we've discussed introducing other types of "capability" bits to complement the file-type concept. Right now a couple of things indicate to libgnomevfs and an application what sort of operations are valid on a given URI: * whats the fileinfo->type? * whats the fileinfo->mime_type? * is there an entry in the method's GnomeVFSMethod struct? * does the operation return GNOME_VFS_ERROR_NOT_SUPPORTED? None of these do a good job of describing URIs that don't follow the rules we expect of local files or directories. For WebDAV we ended up inventing a magic mime type: x-directory/webdav because we want to be able to treat WebDAV "collection" URIs as both HTML files and as a directory. If we could simply describe them through GnomeVFS as a resource of type text/html that support both directory operations and file operations I feel that would be better. Anyway, I'm not sure how connected these two are - I think they probably are related and can be implemented in similar ways. Seth cleverly padded a bunch of structures that we were expecting to want to change in GnomeVFS 2.2 with void pointers. This means that we can extend the GnomeVFS structure by defining a new structure and replacing one of the "reserved" pointers with a pointer to that new structure. One of these was definately intended for a structure that would contain some kind of capability information. So yes, the right patch will be accepted :) It seems like you've been thinking about the problem the same way I have. Ian
Attachment:
signature.asc
Description: This is a digitally signed message part