Syncthing Conflict Files: Compare Both Copies Before Deleting

A file named notes.sync-conflict-20260708-142530-ABCDEFG.md has appeared beside notes.md. Both open, both contain useful work, and Syncthing has finished transferring them. Which one should you keep?

Keep both until you have compared their contents. A sync-conflict copy preserves a competing version; the suffix does not mean the file is corrupt or disposable. Syncthing documents that conflicting edits can produce a renamed copy, which then synchronises like an ordinary file. Its explanation of conflicting changes describes that behaviour.

This guide covers existing conflict copies in ordinary Send & Receive folders on desktop computers. It uses official documentation and source code, with an illustrative recovery workflow rather than a claim of hands-on testing.

What a conflict copy tells you

Imagine a shared note on a desktop and a laptop. While the laptop is offline, you add a paragraph there. Before those changes reach the desktop, you edit the desktop’s copy too. The two devices now have competing edits.

Syncthing can preserve one version under a name containing .sync-conflict-, followed by a date, time and device identifier, while another keeps the original name. It does not decide which text expresses your intentions. The official synchronisation guide explains why conflict copies are propagated between devices.

The filename in the opening is invented to show the pattern. In the source for Syncthing 2.1.2 , the naming function uses the current time when it constructs the conflict name. That timestamp is not a verdict about which document contains your best work. Compare the contents before choosing.

Preserve the candidates before changing the shared folder

Our recommended first move is to stop editing the affected file on every device. Close the applications that have it open, including any editor that saves automatically. Coordinate with anyone else using the shared folder so they do not keep changing it during the comparison.

Copy the original-named file and every related conflict copy into a separate recovery location outside all folders synchronised by Syncthing or another service. Copy them; leave the shared originals in place for now. Use subfolders named for each device if different machines hold different candidates, so one recovery copy does not overwrite another.

Open those recovery copies and confirm that they contain the material you expect. If an offline device might have additional work, preserve its local files before reconnecting it. The point is to collect the candidates before asking synchronisation to change them again.

With those copies protected and the editing applications closed, connect the participating devices and let their existing changes finish synchronising. If that produces additional conflict copies, preserve those too before choosing your final result. Do not reconcile against one device’s stale view while another still has work waiting to arrive.

Syncthing’s backup FAQ explains why another copy in the same synchronised set is insufficient protection: changes and deletions propagate. A separate recovery location gives you something stable to return to while you decide.

Compare the actual changes

For a text file, open the recovery copies side by side or use a comparison tool you already trust. Look for additions, deletions and replacements. The largest file is not automatically the most complete: a deliberate deletion may be the change you wanted.

Here is an illustrative comparison:

• The original-named note contains a corrected meeting time, but lacks a paragraph added on the laptop.
• The conflict copy contains the new paragraph, but still shows the old meeting time.
• A useful resolution keeps the corrected time and the new paragraph in one document.

Choosing either file wholesale would lose something. Write the combined result into a new working copy in the recovery location, and review it before placing it back into the shared folder.

For a spreadsheet, drawing or other structured document, use the application that understands that format. Check the sheets, objects or revisions that matter. If the application cannot combine the versions safely, retain both and choose deliberately; renaming a file does not merge its contents. For databases and game saves, follow the application’s recovery guidance rather than combining bytes by hand.

Put one reviewed result back into circulation

Once you have preserved all candidates and agreed on the result:

1. Choose one device for the reconciliation and keep the affected file closed elsewhere.
2. Copy the reviewed result into the shared folder under the intended original filename. Keep your recovery copies outside it.
3. Allow Syncthing to transfer the result to the connected devices. Check for pending items or errors before opening it elsewhere.
4. Open the file on another device and verify the changes you meant to keep. In the note example, check both the corrected time and the added paragraph.
5. After that check, remove the redundant conflict copies from the shared folder if you no longer need them there. Retain the separate recovery copies until you are confident nothing is missing.

These steps assume a Send & Receive folder, which both sends and accepts changes. A Receive Only folder does not distribute local edits in the same way. Check the folder-type documentation before using a different mode as the reconciliation point.

Avoid treating Override Changes or Revert Local Changes as a general “fix conflict” button. The documented operations can overwrite or delete files to enforce a folder’s chosen direction. They do not compare the paragraphs or spreadsheet cells you wanted to retain.

Why versioning helps, and where it stops

Syncthing’s file versioning can archive an older file when an incoming change replaces or deletes it. It is configured per folder and per device, and is disabled by default. Crucially, it applies to changes received from other devices: it does not archive the previous contents of a file you overwrite locally on that same device. The versioning guide explains this boundary.

For example, enabling versioning on the desktop can preserve an older desktop copy when a laptop’s change arrives. It does not make every unsaved or overwritten laptop edit recoverable. Check where versioning is enabled and practise restoring a harmless test file before relying on it.

Conflict-copy retention is also configurable. The 2.1.2 implementation can remove excess conflict copies, and setting Max Conflicts to zero prevents that preservation step. Reducing the count to make a folder look tidy gives you fewer candidates to recover from; it does not reconcile competing edits.

Make the next handover explicit

For a file you edit on several devices, use a simple handover: save and close it on the first device, let its changes reach the second, then open it there. If you worked offline, bring that device back into sync before continuing the same file elsewhere.

When a conflict does appear, success means the reviewed contents are present on the devices that need them, with a separate recovery copy still available. A tidy filename alone cannot tell you that the work survived.