(Illustration by Gaich Muramatsu)
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/Received on 2005-04-27 18:52:58