Hi Greg,

On Tue, Jan 31, 2006 at 04:00:07PM -0500, Greg Troxel wrote:
> That makes sense

thanks.

>   if the coda owner has a uid/coda-uid mapping, invert it and use the
>   local uid.

I guess you suggest the Coda kernel module to maintain mappings
for each local uid to Coda realms' uids for all realms where the local uid
sometimes modifies files? Note that the same local uid can act
as different Coda ones, for the same realm, at different times.

Note also that such mapping would be local to a client and hence
in general different for the same human user on different Coda clients.
I'd never want to maintain mappings on all Coda clients I happen to use.

>   if the calling user's coda uid is in the acl, enable group bits

Greg, you are opening a can of worms. DFS tried hard to make acls coexist
with *nix bits, but there were extremely few users who really comprehended
the logic. I suggest leaving all bits explicitely irrelevant and intact.

>   if System:AnyUser, enable other bits

Same here. If not otherwise, you'd indicate to the users that unix bits
might have sence on Coda, despite the semantics being fundamentally
incompatible. They will chmod and chown and do tricks
trying to make it work the *nix way - which is going to fail.

(if the group/world bits are relevant for some program, they can be
explicitly set, no more magic has to be involved)

I am quite convinced of the outcomes because of the real experience.
Hope we shall not make such kind of mistake with Coda.

Regards,
--
Ivan