(Illustration by Gaich Muramatsu)
(Illustration by Gaich Muramatsu)
Here is a common answer that I send out about once every week or two.
We don't provide UNIX File System semantics, but so called AFS or session semantics. Coda clients do not propagate changes in a modified file until the file is closed. It has many advantages over UNIX semantics, where written blocks are written back at random because of memory pressure or whatever and refetched as soon as a changed version is seen. With session semantics we are guaranteed that the copy on the server is either a complete older version or a complete uptodate version of the file, but it will be consistent and will never have a few old data blocks mixed in with a couple of new ones.
So the 'dirty' file won't get propagated from client1 until the ldap daemon or mysql daemon decides that the 'modifying session' is over (i.e. until it closed the filedescriptor). As a side-note, during (write-)disconnected operation we have the optimization that if the file is immediately reopened we optimize away the fact that we needed to push this copy to the server as we know it's going to be overwritten with even newer data.
And once the updated copy of the file has finally reached the servers, other clients won't get this update until they have ended their 'session' by closing their cached copy of the file. Until they reopen the file, they will pretty much always be looking at the consistent, but possibly quite stale copy. When both clients write to the file, the second write attempt that reaches the server is automatically rejected and the client is disconnected from the filesystem. He updated a stale file, and we ended up having 2 diverging versions of the same file. It is a local-global or reintegration conflict, which the user has to repair before he can continue.
So Coda clearly won't solve the replication problems of specialized applications, only the class of dumb applications that only do one simple things with files will work nicely. i.e. you text editor opens the file to read it, then closes it. Then you can make any modifications over whatever long period in the editor's scratch buffer. Then when you save the file, the editor first checks if the on-disk copy has changed, and when it is still identical opens the file, writes and closes.
A database application on the other hand, opens the database when it starts up, initializes a bunch of in-memory datastructures that are used to speed up access to the database and keeps the file open while it modifies the database in place. fsync or direct disk access are used to force consistent transaction boundaries. During this it uses extensive locking to manage concurrent access by multiple threads.
As far as I know, it's not possible to even run 2 mysql daemons that access the same database files on one machine and have them reliably work. So how would Coda suddenly be able to make this work between different machines, we've invented replication magic?
Jan