On Tue, Jan 31, 2006 at 05:49:59PM +0100, Ivan Popov wrote:
> I am asking - as I did for a long time - to implement a behaviour
> more consistent with global filesystem usage, namely stat() to return
> the local uid of the calling process as the file "owner".
> 
> The needed change in the kernel module(s) appears to be simple, and I plea for
> it to be done in upstream. I am a realm administrator, I do not and can not
> administer Coda clients of my users. Even if I would decide to force them
> to use my own tweaked kernel module, I couldn't!

But why would the calling process be the correct userid. In fact
anything that tries to use chown will probably want to set the ownership
to something that is explicitly _not_ the calling user, and as a result
still fail as horribly as it does now.

> The historical AFS-like behaviour was inspired by
> "ALL clients are administered together with ALL servers".
> That behaviour is incompatible with the global scope of Coda and is now
> a real pain.

As far as I know, the AFS way was to use a modified ls binary which uses
an ioctl to map the filesystem identities to usernames. i.e. instead of
relying on the /etc/passwd, NIS, or LDAP database lookups, ask venus,
which asks the server, which performs a lookup in the pts database.

It is similar to how Coda shows the ACLs, the getacl RPC returns the
usernames as strings because there is no simple mapping to local
userids.

Since Coda doesn't really use identities, maybe everything should be
mapped to a fixed local identity (coda/coda), but allow chown by anyone,
but not actually forward this change to the servers. So the setting will
only survive for as long as the object is locally cached, which
hopefully will be long enough to avoid problems with applications that
expect UNIX semantics.

Not having to update owner/group/mode attributes would reduce write
traffic and as a result there is less potential for conflicts.

Jan