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.

> Correct, in connect mode the we don't return back to the application
> until the file is stored on all replicas. So if you're using 2 replicas
> it will end up transferring twice the amount of data. On top of that,
> the Coda server will force all the changes do disk (and probably even
> flush/truncate the RVM) before it returns to the client. In addition,
> the client probably performs at least 4 operations for every file,
> (create, store, chown, chmod, possibly utimes) and there is no
> coalescing every operation becomes a separate RVM transaction, along
> with a bunch of RVM flushing/truncating/fsyncing.

	Yuck.

> type of reintegration conflict. So write-disconnected is not really the
> best solution especially for new users that are just taking their first
> steps with Coda.

	Yeah, I'd like to avoid conflicts completely if possible.  The speed
issue is really only a problem when unpacking tars and rpms and such.
During normal operations it won't matter much.

	This is very good info.  I hope it makes it into the manual. :-)
Thanks for taking the time to clarify things.

-- 
Patrick Walsh
eSoft Incorporated
303.444.1600 x3350
http://www.esoft.com/