Re: adding new info to GnomeVFSFileInfo

["Nils Philippsen" <nils wombat dialup fht-esslingen de>]

[ MAINTAINERS, please read below: ]

Christophe Fergeau said:
>
>>
>> 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.

You raise a good point. (Note to myself:) I'll have to take read-only
mounted stuff into account as well.

> 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.

Yes.

> 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.

Oh, I'm not the one to drop any patches here. Basically, I'm just the guy
who wants to fiddle with ACLs from within Nautilus and babbles about how
GnomeVFS needs to be extended in order to achieve that since. I've yet to
submit any patches because I've not produced anything I consider worth
submitting. You'd have to ask Seth or Ian or someone else to drop your
patches instead ;-).

Whether I will be ready for 2.2 freeze, I can't say. Because what I
propose would merely be API addition and all relevant structures have way
enough padding I don't see a reason why it shouldn't slip in at a later
point.

> 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...

[ MAINTAINERS, please read from here at least: ]

You raise another very important point: I ask you (and the maintainers) to
expose permissions/access only via methods, not struct members (e.g. not
GnomeVFSFileInfo::permissions but gnome_vfs_fileinfo_permissions() and
gnome_vfs_fileinfo_access() -- it should suffice to publically dissuade
from using the permissions member directly and using methods instead).
This way I could just alter the relevant methods with my patch so that
"legacy behaviour" will be emulated (where this makes sense).

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?