coda_at_bobich.net writes:

 > > I offer you a simple way to avoid maintaining an extra service
 > > and you refuse, why? :)
 > 
 > Something to do with the fact that I need a centralized authentication 
 > service anyway. :)

Sure, but at least part of Rune's point is that merely hooking it up
will have maintenance implications (eg, user reports like "[my laptop
is busted, my boss gave permission to use my daughter's,] why are all
my files suddenly owned by UUCP, is the server broken or hacked?")

 > > People have very hard time thinking beyond "a better NFS" which Coda
 > > is definitely not.
 > 
 > It's largely to do with the fact that the standard UNIX tools (chmod et 
 > al) don't work sanely in a coda environment. Things don't just behave one 
 > might expect them to. The integration is just not seamless enough. Some of 
 > it may be correctable, some of it may not be.

It's not correctable in general.  Coda simply doesn't provide POSIX
semantics.  That was a lot of what NFS was about, providing POSIX
semantics in a networked file system (trying, anyway), basically you
can think of your ethernet as an IO bus to which disks are connected.
But Coda is truly distributed, there is no single disk on which a file
can be said to reside.  For example, Coda's open() semantics are quite
shocking to most people.

 > >>> When someone e.g. tries to implement such a feature,
 > >>> he or she is missing the point.
 > >>
 > >> Maybe so, but that doesn't mean that seeing the right username in ls -l
 > >> output is a bad thing. It's useful.

Coda doesn't have an equivalent to "owner" or "group" rights.  The
question is "what do you propose to put there?"

So, what *is* the right username to list for owner?  Usernames don't
have Unix semantics.  Should every non-admin user who has the right to
change the ACL of a file (the main distinguishing feature of a POSIX
file owner) be listed as owner?  Should the creator of the file be
listed as owner?  What if she doesn't have "change ACL" rights any
more?  How about group?  Should every Coda group that has an explicit
ACL assigned for that file be listed there?

Sure, in your situation you may wish to (attempt to) emulate POSIX
semantics, but Coda's suite of operations can't be restricted to that.

 > database. I know this sounds crazy, but maybe a ls replacement wrapper 
 > that calls ls or coda's equivalent depending on what is mounted?

Seems reasonable, but it shouldn't be called "ls".