(Illustration by Gaich Muramatsu)
> Also, I promised a "optimizing coda 6" document and I have a draft of > it. I'm attaching it in rtf format in case it is useful to someone. Thanks Patrick, a nice document and a good summary. I have a remark (where I think you rely on my own post) "Volumes are used as administrative units to specify owner and group permissions, quotas, backup strategies, etc." There is a couple of things to formulate differently: - the "owner" has no meaning on Coda, and the corresponding "access bits" are abused in a controversial way (they limit access to the file for all, but are not enforced by the servers, so anyone with a modified client can go around that access "limitation") so it is best to ignore them for all purposes except cosmetical - "group" bits are totally irrelevant on Coda, ignore (Coda groups are totally different from Unix ones) With other words, there are no "owner and group permissions". - real access control is done via ACLs (access control lists), and they are per-directory, not per-volume (nor per-file). I referred once to a setup where I have 4 volumes per user, having different backup strategies, different quotas and also different default ACLs on their root directories. I would not _have_ to separate volumes for the last reason, it could be done inside one volume. The main idea was to separate different kinds of data into separate volumes. Another issue: The size of RVM on the client is calculated very differently compared to one on a server. Venus allocated RVM not only for files or directories, but also for file changes which can happen in disonnected mode. It makes the client a lot more RVM-hungry than the server for the same amount of data (number of files and directories, which on the other side is usually a lot higher on a server than on a client) Again, I think your document is very useful. Regards, -- IvanReceived on 2005-04-08 17:43:45