Beyond the Wire: Folder Authority, Recovery, and Untrusted Replicas

Syncthing's transport and convergence machinery does not decide every operational policy for the user. This chapter focuses on the choices that determine who may author a folder, what older content can be recovered, and whether a participating storage device may read the data it holds. The practical judgment is to treat send-only, receive-only, versioning, and untrusted-device encryption as policy layers over the same trust-and-reconciliation system—not as interchangeable backup buttons or a promise that one endpoint can be made harmless by configuration alone.

A folder mode is a decision about authority

The default send-and-receive folder gives both the local device and the shared cluster a voice. Local changes are scanned, announced, and made available to peers. Changes selected from the cluster are applied locally and redistributed according to the ordinary synchronization flow. This is the natural choice when several devices are genuine co-authors of the same working set, but it also means that a mistaken deletion or edit can become a cluster-wide change unless another recovery layer is present.

A send-only folder changes that authority. It continues to publish local changes, but it does not apply updates received from the cluster. This is useful for a reference copy: a workstation or archival source whose local state should be the version that other devices follow. The reference device can become visibly out of sync because it still receives knowledge that other devices have changed. The user must then make an explicit override decision to enforce the reference copy's state across the cluster.

That override is powerful precisely because it is not automatic. It can overwrite changes made elsewhere and remove items that are absent from the reference copy. Send-only therefore does not mean “safe backup” by itself. It means “this folder's local state has authority when the user chooses to assert it.” The safety benefit comes from making that direction visible and requiring a deliberate action instead of silently treating a reference copy as the winner at every moment.

A receive-only folder makes the opposite choice. It accepts cluster changes and can redistribute what it receives, but local changes are not published as ordinary authorship. This suits a mirror or a destination where local edits are not supposed to influence the shared state. If someone changes a file locally anyway, Syncthing preserves the change and marks the folder as locally changed rather than pretending that the edit should become a new cluster version.

Receive-only also provides an explicit revert operation. Reverting tells Syncthing to discard or undo local changes so that the destination can return to the cluster's selected state. If a local change conflicts with a later cluster change during ordinary operation, a conflict copy may be created locally, but that local alternative is not sent out as a new authoritative change. The direction matters: send-only lets a reference source override the cluster, while receive-only lets a destination reject its own local divergence and follow the cluster again.

These modes show why synchronization is not merely a property of a connection.