Re: adding new info to GnomeVFSFileInfo

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

Christophe Fergeau said:
>> So yes, the right patch will be accepted :) It seems like you've been
>> thinking about the problem the same way I have.
>>
>
> So the patch in this email makes the changes to GnomeVFSFileInfo that I
> described in a previous mail. It also modifies the file: and ssh:
> methods so that they correctly fill the new fields. (it may not apply
> correctly with the other patches I posted on this list)
>
> Comments are welcome, in particular comments about whether it is the
> right approach or not.

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?

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?