Re: adding new info to GnomeVFSFileInfo

[Christophe Fergeau <teuf users sourceforge net>]

> 
> I think the way you do it basically does the same as "copying" the r,w,x
> bits valid for either user, group or others (depending on the relation
> "your" user has to the file). Right?
> 

Currently, yes, with the little subtlety (don't know if this is written
that way) described in access man page. 
The problem currently is that most apps using gnome-vfs to access files
will want to know that: "can the current process read/write/execute this
file ?". They aren't interested at all about getting extended access
information about an uri. If the framework you describe can provide a
function to easily get this information, and if it can be ready by the
end of october (which is the 2.2 freeze date iirc), then fine, just drop
my patch. Otherwise, I really think this patch (or another patch
returning the same kind of information) should go in for 2.2 One thing
not to forget though is that if these flags are added to gnome-vfs for
now, they'll have to stay for an undefinite amount of time...

Christophe

> This sounds feasible as a short-term workaround for me. In the long term
> I'd want to avoid two quirks partly inherent to the concept of permissions
> as of now in GnomeVFS and partly of your patch:
> 
> - Unix/Posix only semantics (r,w,x && only additive permissions)
> - unnecessary redundancy in the struct (i.e. you could also store whether
>   we belong to user, group or others in relation to this file and then
>   return the relevant bits from "permissions" though that would mean more
>   work, i.e. determining "who I am" instead of just running access()/access
>   locally or via ssh)
> 
> These are issues I want to tackle with enhanced[ ]/improved[ ]/extended[ ]
> permissions (tick one, please :-).
> 
> FYI and for starters, I have spent much thought about how to handle users
> and groups because they are needed for handling permissions (e.g. listing
> users valid for a file system so that you can give or take permissions on
> a file, etc.). I have come to the conclusion that a framework to map
> users, groups and their relations would be way beyond the scope of what
> we(I?) hope to achieve in this context (this would rather be glib or some
> other general purpose stuff).
> 
> In order to get the functionality what we need, I'd like to just have very
> simple classes which keep a unique identifier (in the scope of the
> relevant file system that is) which is either a (long) integer or a string
> (for SMB, DAV and the like) and a short and probably a long name (strings)
> to display the user/group in the UI. These objects would be "married" to a
> "storage place", i.e. a "namespace" in which a user/group is valid, this
> would in most cases relate to a machine and possibly a protocol (i.e.
> "file://" (i.e. local) or "smb://machine1" or "nfs://machine2"). This
> "should just do" for what we need.
> 
> Oh, and this time I won't make a humble request for comments: Comment now
> or risk to suffer later is the motto.
> 
> Cheers,
> Nils
> -- 
> Nils Philippsen / Berliner Straße 39 / D-71229 Leonberg // +49.7152.209647
>    nils wombat dialup fht-esslingen de / nils redhat de / nils lisas de
>    PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
>        Ever noticed that common sense isn't really all that common?
> 
> 
> 
> _______________________________________________
> gnome-vfs-list mailing list
> gnome-vfs-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-vfs-list