Hi Patrick,

On Wed, Apr 27, 2005 at 04:51:39PM -0600, Patrick Walsh wrote:
> 	Thanks for responding so quickly.  This is interesting stuff.
> 
> > I think Coda doesn't allow someone to change the owner/group id of a
> > file if the user doesn't have admin rights from the directory ACL. NOt
> > sure though, and since Coda ultimately relies on the ACL based
> > permissions it doesn't matter all that much.
> 
> 	It doesn't matter, but rpm fails.  Turns out that it's failing when
> trying to change the owner of a symlink.  It can be reproduced by doing
> a `chown -h newuser symlinkfile`.  I'm sure we can workaround it, but I
> think it's a coda bug.  An strace shows the failure happens in the
> lchown() system call.  The chown() system calls seem to work fine.

As file owner has no semantics on Coda (I think symlink owner has no semantics
even on Posix :) , it could as well ignore the call and return success.
But that's not enough.
There is another issue - what and how Coda can present to the programs
as the file "owner". It is not really solvable, any global filesystem
and Posix semantics are inherently incompatible.
Current behaviour is a workaround which is definitely "wrong"
in many situations.

I would suggest a "user-space" workaround which works for most purposes:
at the time you run rpm or another program which believes it has
a local filesystem - give it a local filesystem.

cp -a /coda/.........../dir/. /tmp/dir
rmdir /coda/.........../dir
ln -s /tmp/dir /coda/.........../dir
  [run a troublesome program which modifies /coda/.........../dir]
rm /coda/.........../dir
cp -a /tmp/dir/. /coda/.........../dir

Otherwise there is no full solution for such needs
(it is a problem with the needs themselves as rpm is designed
for _local_ filesystems and it can go to extremes to ensure that)

Regards,
--
Ivan