1.9. Repairing Conflicts

As a result of Coda's optimistic replica management, object replicas can conflict on different servers. A conflict arises when the same object is updated in different partitions of a network. For instance, suppose a file is replicated at two sites (say, serverA and serverB). If these two sites become partitioned and a user on each side of the partition updates the file (userA updates the file on serverA while userB updates the file on serverB), the file will be in conflict when the partition ends. Conflicts may also arise at the end of disconnected operation.

Coda guarantees conflict detection at the first request for that object when both servers are accessible. When a conflict is detected, Coda attempts to perform automatic conflict resolution. In simple cases, the conflict will be resolved automatically, a process which is transparent to the user except for a time delay in accessing the object. However, in more difficult cases, automatic conflict resolution fails and the object is marked in conflict . File system calls on an object which is in conflict fail with the same error code as if the object were a dangling, read-only symbolic link (usually, ENOENT ). The conflict must be resolved by a user with appropriate access to the object. To help users resolve conflicts, Coda provides a repair tool which is discussed in Section 2.6 .