Apps that touch the filesystem must handle concurrent external edits

What it is

A document is open in an editor when a cloud-sync client writes a new version at the same path, or someone else saves the same file from another program. External concurrent modification is the price of reading and writing the filesystem directly: the app is not the file’s only author. The copy on disk can be changed, locked, or deleted without its knowledge. Conflicts in collaborative editing are people meeting inside one document model. This is apps meeting apps, and apps meeting a sync disk, on a path. Do not assume that after Open the file belongs only to you.

Why it happens

Direct access leaves the file on a public map. Open usually reads a snapshot into memory; later edits happen in the app. Bytes on disk can be replaced in Finder, restored from backup, quarantined by antivirus, or exclusive-locked by another process at any time. If the app only writes memory back over the file at Save, last write wins and the external version vanishes silently. If Save notices a changed timestamp and only reports failure, people do not know whose content is on disk now. A file watcher can notify on external writes, but by then memory may already hold unsaved edits; both copies are “newer,” and there is no natural winner. Opening exclusive can block others, and also turns “glance in Preview” into an error, and it will not block a write on another machine against a network volume.

Studying it

Take one file, edit it in the app under test, and change the on-disk copy with another program or a sync client. Compare silent overwrite, read-only lock, and keeping both sides after a conflict.

Independent variables: when the external write happens (open, no edits / unsaved edits / during save), exclusive lock or not, whether the conflict UI keeps both versions. Dependent variables: whether data is lost, whether people can point to “which copy was the outside edit,” success restoring the overwritten version, rate of mistaking the external update for their own action.

Two windows in the lab standing in for “external” let people know they touched both sides, and will overestimate detection. A harder disruption is a real sync client or a script changing the file while the app is unfocused. Do not count intent conflicts from several people editing online on this claim—that is merging inside a document model, not two byte copies on a path.

Where it stops holding

A read-only viewer has no unsaved edits; an external update can replace the whole file, and the conflict collapses to “refresh or keep what is on screen.” Databases and professional project files use their own lock protocols; a system file lock is not enough, and “who holds it” still has to be expressed in the app. Pure cloud documents fight on the server; the local path is not the battlefield. Apps that autosave often make conflict windows more frequent; if they ignore external writes, autosave itself is the machine that overwrites the outside.

Applying it

• After open, watch the path for modify, delete, and replace. If an external write arrives and memory holds unsaved edits, stop covering the disk with memory.
• On conflict, keep “this version in memory” and “that version on disk” side by side or switchable; never keep only whichever wrote last.
• If save fails because the file is in use, name who holds it and what can be done (close Preview, save as); do not only say it cannot save.
• Verify: change a few characters in the app without saving, change the same file from another program and save, return to the app. A conflict must appear; neither version may vanish silently; both must still open. Try saving while the file is locked; the error should say who holds it.

Related

• Within the group: K2.12.1 Desktop apps can read and write the user's filesystem, not only a sandbox · K2.12.2 OS differences in paths and naming break cross-platform ports · K2.12.4 Sandboxing requires apps to declare and request a file-access scope
• Adjacent: I3.04 Sync conflicts · H8.07 Collaborative editing conflicts
• Search terms: file locking · external modification · conflicted copy