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/
signature.asc
Description: This is a digitally signed message part
