How Syncthing Handles Conflicts

A conflict occurs when two devices modify the same file while they are not connected to each other. When they reconnect, Syncthing must decide what to keep. Understanding this mechanism prevents data loss surprises.

Learning Focus

Syncthing never silently discards data. When a conflict is detected, it preserves both versions — the winner and the loser. Your job is to know how to find and clean up conflict files.

When Is a Conflict Created?

sequenceDiagram
  participant A as Node A (Laptop)
  participant B as Node B (NAS)
  Note over A,B: Both nodes are disconnected (e.g., no internet)
  A->>A: Edits report.docx → v2
  B->>B: Edits report.docx → v2 (different edit)
  Note over A,B: Nodes reconnect
  A->>B: "I have report.docx at 09:15, hash=xxx"
  B->>A: "I also have report.docx at 09:22, hash=yyy"
  Note over A,B: Conflict detected — both modified since last common state
  B->>B: Renames loser → report.sync-conflict-20260413-...docx
  B->>B: Downloads winner (latest modification time) → report.docx

The Conflict Naming Convention

Syncthing always keeps the winning file at the original filename. The losing file is renamed using this pattern:

<basename>.sync-conflict-<date>-<time>-<deviceID>.<ext>

Example:

report.docx                              ← winner (newer mod time)
report.sync-conflict-20260413-091523-K3X2R2T.docx  ← loser

The device ID in the name is the ID of the device that created the losing version.

The Conflict Winner Rule

Syncthing uses a deterministic rule to decide which version "wins":

1. The file with the higher modification time wins.
2. If modification times are equal, the file from the device with the lexicographically larger Device ID wins.

This rule is applied identically on all nodes — no central authority needed.

warning

Modification time is not edit time. Modification time can be affected by file copies, migrations, and system clocks. Ensure system clocks are synchronized via NTP on all nodes.

Finding Conflict Files

Conflict files are named with .sync-conflict- so they're easy to search:

find-conflict-files.sh

# Find all conflict files in a synced folder
find /var/www/html/uploads -name "*.sync-conflict-*"

# Count total conflict files
find ~/Documents -name "*.sync-conflict-*" | wc -l

# Find conflicts and show them sorted by date
find ~/Documents -name "*.sync-conflict-*" | sort

Resolving Conflicts Manually

Once you find conflict files:

1. Open both versions and compare them (use diff or your editor).
2. Decide which to keep (manual merge if needed).
3. Delete the conflict file (the .sync-conflict-* one).
4. The deletion of the conflict file will also sync to all peers.

# Compare conflict versions
diff report.docx "report.sync-conflict-20260413-091523-K3X2R2T.docx"

# Or use vimdiff for interactive comparison
vimdiff report.docx "report.sync-conflict-20260413-091523-K3X2R2T.docx"

# Once resolved, delete the loser
rm "report.sync-conflict-20260413-091523-K3X2R2T.docx"

Configuring Max Conflicts

By default, Syncthing keeps up to 10 conflict copies per file. After 10, it starts replacing older conflict files.

Change this limit in the GUI:

1. Edit Folder → Advanced tab → Maximum Number of Conflict Copies.
2. Set to 0 to disable conflict file creation entirely (not recommended — you lose the safety net).

Or directly in config.xml:

<folder id="docs" ...>
  <maxConflicts>10</maxConflicts>
</folder>

Common Scenarios

Scenario	What Syncthing does	Your action
Offline edits on two devices	Creates .sync-conflict-* for loser	Manually merge and delete loser
Internet outage during edits	Same as above	Same
Same file edited within milliseconds	Winner = higher mod-time	Verify winner is correct
Clock skew (NTP not configured)	Wrong winner may be chosen	Fix NTP, then manually reconcile

What's Next

• Preventing Conflicts
• Versioning and File History