When Two Devices Edit the Same Note

A sync conflict happens when two devices edit the same note while offline, then reconnect and disagree about which version is real. The software has to pick a strategy: throw one edit away, fork the file into two copies, or merge the changes. Which strategy it uses — and what format your note is in — decides whether you lose work.

You have seen the symptom even if you never learned the name. A file appears called Notes (conflicted copy).md, or Seven Wonders 2, or meeting-notes (1). Dropbox describes it plainly: "A conflicted copy is a file that Dropbox creates when multiple people edit the same file at the same time," and "The editor's username, 'conflicted copy', and the save date will be added to the filename." ¹ Apple documents the same failure for iCloud Drive. ²

This post explains why it happens, the three strategies tools use to resolve it, and why the format of your note is what decides whether the conflict is recoverable.

Why do I get conflicted copies of my notes when I sync?

A conflict is created when two devices change the same note before either sees the other's change — usually because one was offline. When they reconnect, the system finds two newer versions of one file and no reliable way to know which one you meant. Apple documents this precondition for iCloud Drive directly. ²

In Apple's own words, conflicts "can occur when you use more than one device that's not connected to the internet to edit the same document stored in iCloud Drive." ²

This is not a rare edge case. It is the default behavior of a distributed system. The moment your notes live on more than one device, you have a tiny version-control problem — the same offline-then-reconnect situation that decides what happens when the network fails.

The phone you edited on the train and the laptop you opened at home both believe they hold the truth. Sync is the negotiation between them, and a conflict is that negotiation failing politely instead of silently overwriting.

Martin Kleppmann, a distributed-systems researcher at Cambridge, names the whole problem set in one sentence: tools handle conflicts in one of three ways — "some systems let the user manually resolve them; some systems choose one version as the winner and throw away the other versions; and some systems try to merge concurrent updates automatically." ³ Everything below is those three sentences, expanded.

Strategy one: last-write-wins, where an edit silently disappears

Last-write-wins (LWW) is the simplest and the most dangerous strategy. When two versions conflict, the system keeps one — usually the most recent timestamp — and discards the rest. There is no copy, no warning, no diff. The losing edit is gone, and you often do not notice until you go looking for a sentence that is no longer there.

The danger hides inside features that look safe. iCloud Drive offers a dialog to "keep both" versions when it detects a conflict — but Apple warns what the dialog actually does to the rest: "Versions you don't select are deleted from iCloud Drive on any computer, iPhone, or iPad with iCloud Drive turned on." ² Click through that dialog quickly, pick the wrong version, and the other device's work is deleted everywhere at once.

Who should not rely on last-write-wins: anyone who edits the same notes on two devices and cannot afford a silent loss. That is most people. LWW is acceptable for throwaway state — a cursor position, a last-opened timestamp — and unacceptable for the words you actually wrote. If you cannot tell whether your sync tool uses it, assume it does, and stop editing the same note on two offline devices at once.

Strategy two: the conflicted copy, where nothing is lost but the work moves to you

Forking a conflicted copy is the safest crude option: instead of choosing a winner, the system keeps both versions as separate files and hands the reconciliation back to you. Dropbox does this with its (conflicted copy) suffix. ¹ Nothing is deleted — but nothing is merged either. You now own a manual chore the software declined to do.

This is the failure mode the local-first research paper from Ink & Switch puts at the center of its critique. Its authors — Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan — observe that "in old-fashioned software it is problematic for several people to work on the same file at the same time: the result is often a conflict." ⁴ Their Figure 2 shows a Dropbox conflicted copy with a one-line verdict: the user must merge the changes manually.

The worst version of this strategy belongs to proprietary note apps. The same paper describes Evernote's behavior: a concurrently changed note is moved to a "conflicting changes" notebook, "and there is nothing to support the user in resolving the situation — not even a facility to compare the different versions of a note." ⁵

Two copies, no diff, no merge tool. You are left to eyeball two opaque blobs and guess. Who should not rely on bare conflicted copies: anyone whose notes are locked in a format they cannot open, compare, and merge with ordinary tools.

Strategy three: three-way merge, the model plain text can borrow

Three-way merge is what version control has used for decades, and it is the most forgiving strategy for text. It compares both edited versions against their common ancestor: changes to different parts combine automatically, and only genuine overlaps — the same lines touched on both sides — are flagged for you to resolve. You fix the overlap; the rest merges itself.

Git's own documentation describes the mechanism precisely. Non-overlapping changes, "that is, you changed an area of the file while the other side left that area intact, or vice versa," are "incorporated in the final result verbatim." Only when "both sides made changes to the same area" does the tool stop: "Git cannot randomly pick one side over the other, and asks you to resolve it." ⁶

The result is a readable diff, marked with <<<<<<< and >>>>>>>, that shows you exactly what each side wrote.

This matters far beyond developers. A three-way merge needs only one thing from your note: that it is line-oriented text a diff tool can read. Your shopping list, your meeting notes, and your novel draft all qualify. Who should not rely on three-way merge: people whose notes are stored as a binary or proprietary blob, because there is no ancestor and no line structure for the merge to work against.

Strategy four: CRDTs, where both edits converge automatically

A CRDT — conflict-free replicated data type — is the strategy modern local-first apps reach for to make merges automatic, with no central server and no manual step. The local-first paper defines it as a data structure "multi-user from the ground up while also being fundamentally local and private." ⁷ When offline devices reconnect, both changes take effect. ⁸

For years this was theoretically elegant and practically heavy. That is changing. The Automerge project — one of the best-known CRDT libraries — reports large gains in its 3.0 release (2025): pasting Moby Dick into an Automerge 2 document "consumes 700Mb of memory, in Automerge 3 it only consumes 1.3Mb." ⁹

Across the board the team reports it "cut that down memory usage by over 10x, sometimes dramatically more," ¹⁰ with one example of "a document which hadn't loaded after 17 hours loading in 9 seconds." ¹¹ Treat those as the project's own self-reported benchmarks, not independent measurements.

Here is the honest caveat, and it is the one nobody puts on the marketing page: a CRDT guarantees the bytes converge, not that the merged meaning is what either author intended. If two people rewrite the same sentence two different ways, a CRDT can interleave them into clean, syntactically valid nonsense that no one wrote. Who should not over-trust CRDTs: anyone who assumes "automatic merge" means "correct merge." It means consistent, not correct.

The axis that actually decides recoverability: plain text vs a proprietary blob

The strategy matters, but the substrate matters more. The same conflict is recoverable or unrecoverable depending entirely on whether your note is plain text or a proprietary blob. Plain text does not prevent conflicts — it makes them survivable. The worst case becomes a readable file you can diff, not a dead end you have to guess at.

The local-first paper makes the technical point: merge tools are "primarily designed for line-oriented text files such as source code; for other file formats, tool support is much weaker." ¹² A Markdown note is line-oriented text.

When it forks into a conflicted copy, you can open both versions side by side, see exactly which lines diverged, and merge them by hand in minutes — or feed them to the same diff tools developers use. A proprietary note in a binary container gives you none of that. It is Evernote's two opaque blobs with no facility to compare them. ⁵

Steph Ango, the CEO of Obsidian, draws the same line as a design philosophy: "File over app is a philosophy: if you want to create digital artifacts that last, they must be files you can control, in formats that are easy to retrieve and read." ¹³ A conflict is a stress test of exactly that property. The format you chose months ago decides, in the moment of conflict, whether your edit is recoverable.

flowchart TD
  A[Two devices edited<br/>the same note offline] --> B{How does the<br/>tool resolve it?}
  B -->|Pick a winner| C[Last-write-wins:<br/>other edit deleted]
  B -->|Keep both files| D[Conflicted copy:<br/>you merge by hand]
  B -->|Merge automatically| E[Three-way merge<br/>or CRDT]
  C --> F{Is the note<br/>plain text?}
  D --> F
  E --> F
  F -->|Yes| G[Readable diff —<br/>recover line by line]
  F -->|No| H[Opaque blob —<br/>hard to compare]

Figure: How a sync conflict resolves. When two offline devices edit one note, the tool either picks a winner (last-write-wins, which deletes the other edit), keeps both as a conflicted copy you merge by hand, or merges automatically with a three-way merge or CRDT. Whichever path it takes, the format decides the ending: a plain-text note becomes a readable diff you can recover line by line, while a proprietary blob is hard to compare and easy to lose.

How this works when your notes are plain text on your own device

When a note is stored as open Markdown on your own device, a conflict is reduced to its least harmful form: at worst, two readable plain-text files you can diff and merge line by line. The note never becomes an unrecoverable blob, because it was never a blob to begin with. That is a property of the format.

This is the capability MNMNOTE is built around. Notes are stored locally, in open Markdown, on your own device, and work offline — so when sync does what sync sometimes does, the worst case stays inside your reach. The conflict is still a conflict.

But a conflict you can read is a problem you can solve, and a conflict you cannot read is a problem you can only mourn. It is the same logic behind keeping a readable version history of notes you own: when the text is legible, recovery is possible.

The practical defenses are mundane and they work. Let one device finish syncing before you edit the same note on another. Keep your notes in a format you can open with any text editor.

And remember that sync is not backup: a clean merge of two devices is still a single copy if neither was backed up, which is why the 3-2-1 backup rule is a separate discipline. All of this is the concrete mechanics inside the broader case for keeping your data on your own device.

Frequently asked questions

The questions below cover the symptom most people meet first — a duplicate (conflicted copy) file — and the mechanics underneath it: why a conflict happens, how to avoid one across your own devices, whether it means lost data, and what a CRDT actually guarantees. Each answer is sourced to a vendor doc or the local-first research.

What's a conflicted copy? A conflicted copy is a duplicate file your sync tool creates when two devices edit the same file at the same time, rather than overwriting one. Dropbox defines it as "a file that Dropbox creates when multiple people edit the same file at the same time," and adds the editor's name, the words "conflicted copy", and the save date to the filename. ¹

Why do I get conflicted copies of my notes when I sync? Because two devices changed the same note before either saw the other's change — usually because one was offline. Apple states the precondition: conflicts "can occur when you use more than one device that's not connected to the internet to edit the same document stored in iCloud Drive." ² On reconnect, the system finds two newer versions and cannot choose for you.

How do I avoid conflicted copies with multiple devices of my own? Do not edit the same note on two offline devices at once. Let one device finish syncing before you open the note on another. If a conflict still happens, keep your notes in plain text so the two versions are a readable diff you can merge by hand, rather than opaque files you have to guess between.

Is a sync conflict the same as losing my data? Not necessarily — it depends on the strategy and the format. Last-write-wins can silently delete an edit; iCloud's "keep both" dialog deletes the versions you don't select. ² A conflicted copy in plain text loses nothing: both versions survive as readable files you can compare and merge.

What is a CRDT and how does it prevent conflicts? A CRDT is a data structure designed so independent edits merge automatically when devices reconnect — "multi-user from the ground up while also being fundamentally local and private." ⁷ It makes the bytes converge without a manual step. It does not guarantee the merged meaning is what either author intended, so automatic does not always mean correct.

What survives is what you can read

Sync conflicts are not a bug you can engineer away. They are the cost of editing one note in two places, and even a perfect CRDT only guarantees the bytes agree, never that the meaning does. The one thing you control is the format. Keep your notes as plain text you own, and what survives a conflict is whatever you can still read.

If this resonates, mnmnote.com keeps your notes as plain text on your own device, so the worst case of a sync conflict is a file you can still read.