file-sharing semantics

Suppose two people are editing the same shared document at the same time. The moment one types a sentence, when exactly does the other see it, instantly, only after the first person saves, or only the next time the second person reopens the file? Different answers give very different experiences, and none is automatically "right." File-sharing semantics is the precise set of rules an OS or file system promises about what concurrent users see when they read and write a shared file.

Several well-known rule sets exist. Unix semantics is the strictest commonly used: a write by one process becomes visible to all other processes sharing that open file immediately, as if they were reading and writing one shared object, simple to reason about but expensive to guarantee, especially over a network. Session semantics (used by some network file systems) is looser: changes one process makes are not visible to others until it CLOSES the file; everyone effectively works on their own snapshot during their session, which avoids constant coordination but means two people can overwrite each other. Immutable-shared-file semantics sidesteps the whole problem by declaring that once a file is shared it cannot be changed at all, only read, so there is nothing to keep consistent.

Why it matters: the chosen semantics is a direct trade-off between consistency and performance, and it is sharpest exactly where sharing is most useful, across a network. There is no shared memory or instant communication between distant machines, so promising that every machine sees every write the instant it happens is slow or even impossible during a network problem. This is why network file systems often relax to session semantics. The honest takeaway is that "the file changed" is not a single global truth in a shared setting, what each participant sees depends entirely on which semantics the system promises.