Technology

Syncthing Override vs. Revert: Which State Wins?

Syncthing presents two consequential actions for directional folders, but they make different sides prevail:

  • Override Changes appears for a Send Only folder that is out of sync. It imposes that host’s current state on the rest of the cluster.
  • Revert Local Changes appears when Syncthing detects local changes in a Receive Only folder. It removes those changes and restores affected files from the cluster.

Both actions can delete files. The essential distinction is the direction of authority: Override Changes projects local state outward, while Revert Local Changes restores cluster state locally.

The baseline: Send & Receive

A standard Send & Receive folder sends local changes and receives changes from remote devices. Changes can therefore flow in both directions. The directional folder types restrict that flow in different ways. (Current documentation)

A Send Only folder recognizes changes from other devices but does not apply them locally, so the folder can become out of sync. Syncthing describes this mode as intended for a device holding a reference copy, where changes on other devices are unexpected or undesirable. (Current documentation)

A Receive Only folder applies and redistributes changes from the cluster but does not distribute locally made changes. Syncthing lists replication mirrors, backup destinations, and situations where local modifications are not expected or allowed as possible uses. These are documented use cases, not backup or recovery guarantees. (Syncthing 1.29.6 documentation)

The two actions compared

Action Folder type When it appears Direction of authority Documented effects
Override Changes Send Only The folder becomes out of sync Local host → cluster Changed files elsewhere are overwritten by this host’s versions. Files absent from this host are deleted elsewhere.
Revert Local Changes Receive Only Syncthing detects local changes Cluster → local host Locally added files are deleted. Locally modified or deleted files are synchronized again from the cluster.

The current documentation and the supplied documentation for Syncthing 1.29.6 and 1.26.0 give the same substantive descriptions of both actions. These pages establish their behavior in the represented versions, but they do not establish when either action was introduced. (Current, 1.29.6, 1.26.0)

Override Changes makes the Send Only host prevail

A Send Only folder does not apply changes received from other devices. Those differences can leave it out of sync, at which point Syncthing displays a red Override Changes button at the bottom of the folder details. (Syncthing 1.26.0 documentation)

Activating the action enforces the Send Only host’s current state on the rest of the cluster. The documentation identifies these effects:

  • Changes made to files elsewhere are overwritten by the versions on this host.
  • Files that do not exist on this host are deleted elsewhere.
  • More generally, the host’s current state is enforced on the cluster. (Current documentation)

“Override” therefore does not mean accepting remote differences. It means making the local Send Only folder’s view prevail across the cluster.

Consider the authority as moving in this direction:

text example; exact text follows
Illustrative example from this article; not a live system capture.
Send Only host → cluster

The documentation does not separately itemize every possible file state. Its broader wording—enforcing the host’s current state—supports the direction of authority, but not additional claims about recovery, file versioning, or propagation timing.

Revert Local Changes makes the Receive Only folder conform

A Receive Only folder accepts cluster changes while withholding local changes from other devices. Local modifications are preserved when detected and do not cause that folder itself to become out of sync. Other devices can nevertheless show the Receive Only device as out of sync because it no longer has the expected version of a modified file. (Current documentation)

When Syncthing detects local changes, it displays a red Revert Local Changes button on the folder. Activating it undoes the local divergence:

  • A file added locally is deleted.
  • A file modified locally is synchronized again from the cluster.
  • A file deleted locally is synchronized again from the cluster. (Syncthing 1.29.6 documentation)

Here, “Revert” applies specifically to changes made on the Receive Only device. The action restores the affected local contents from the cluster; it does not impose the local changes on other devices.

Its direction is therefore:

cluster → Receive Only host

Opposite directions, but not exact inverses

The two actions are opposites in the limited sense that they resolve divergence in opposite directions:

  • Override Changes: Treat the Send Only host’s state as authoritative and project it outward.
  • Revert Local Changes: Remove divergence on the Receive Only host and restore content from the cluster.

They are not exact inverses for every file state or side effect. The documentation explicitly says that Revert deletes local additions and restores locally modified or deleted files. For Override, it states that changed files are overwritten by the local host’s versions, files absent from that host are deleted, and the host’s current state is enforced more generally. (Current documentation)

Receive Only conflict copies

Receive Only folders have an additional conflict-copy behavior. If a locally modified file is subsequently modified by the cluster, Syncthing documents a sync conflict in which the cluster version wins. The conflict copy is not sent to the cluster because the folder is Receive Only. (Syncthing 1.29.6 documentation)

That local conflict copy is deleted when Revert Local Changes is used. This is separate from the general rule that Revert deletes locally added files and restores locally modified or deleted files from the cluster.

The distinction in one sentence

Override Changes makes a Send Only host’s current state prevail across the cluster; Revert Local Changes removes local changes from a Receive Only folder and restores affected content from the cluster.

The cited documentation defines those action semantics, but it does not establish recovery outcomes, synchronization timing, interactions with file versioning, or whether either action is appropriate for a particular deployment.

Sources and further reading

Back to top ↑

Rody

Founder & CEO · RodyTech LLC

Founder of RodyTech LLC in Iowa. I write practical notes on automation, infrastructure, security, and software decisions for builders and business operators.

No comments yet

Leave a comment

Your email address will not be published. Required fields are marked *