Edits and Deletes Are Just Changes

Chapter 1 made a claim the rest of the guide has to cash: to Syncthing, there is no difference in kind between creating a file, editing it, and deleting it. All three are a new state of the folder, announced to every device sharing it. Here is that claim running.

The edit

Willow's draft gets its next section appended — the community orchard day paragraph. Nothing is pressed, sent, or saved to anywhere; the file is simply changed on disk, and the watcher notices. On juniper, the text arrives:

$ cat share-b/issue-12-draft.md
# The Riverbend Gazette - Issue 12 (draft)

Welcome to the autumn issue of the Gazette, the
newsletter of the Riverbend Neighbourhood
Association.

## Library book sale

The library holds its autumn book sale on
Saturday week. Doors open at nine.

## Community orchard day

Volunteers meet at the orchard gate at nine.
Bring gloves; tools are provided.

$ sha256sum share-a/issue-12-draft.md share-b/issue-12-draft.md
7a46e44560dd3626927f176373ae77256db886a86d2a934c9424e9858f0eabae  share-a/issue-12-draft.md
7a46e44560dd3626927f176373ae77256db886a86d2a934c9424e9858f0eabae  share-b/issue-12-draft.md

A different hash from chapter 3's — of course; the file is different — and the same on both machines. The edit propagated exactly as the creation did, because as far as the protocol is concerned they are the same event.

The delete

Now the masthead, deleted on willow with an ordinary rm:

$ rm share-a/masthead.txt

$ ls share-a share-b
share-a:
events-list.txt
issue-12-draft.md
photos

share-b:
events-list.txt
issue-12-draft.md
photos

Gone from both. No trash can, no "deleted items" view, no grace period, no undo in the GUI — because there is nothing in the model to hold one. Willow announced "the folder no longer contains masthead.txt," and juniper, whose job is to make its folder match, obeyed. The lab checks for the one place a copy might survive:

$ ls share-b/.stversions
ls: cannot access 'share-b/.stversions': No such file or directory

There is no versions folder, because versioning is not switched on yet. Chapter 6 switches it on, and the same delete ends very differently.

Sit with the implication for a moment, because it is the most important sentence in this guide: Syncthing is not a backup. It is a mirror. Delete a file (or encrypt it, or corrupt it) on any device, and the mirror faithfully reproduces the disaster on all the others, quickly and securely. Cloud drives soften this with their own recycle bins and 30-day histories — those are service features, provided by the server Syncthing doesn't have. What protection exists here, you configure yourself, per folder: versioning on the devices (chapter 6), folder types that refuse incoming changes (chapter 8), and — outside Syncthing entirely — an actual backup of at least one device's copy, which nothing in this guide replaces.

The mirror is also the virtue, and it is worth saying so: a delete that propagates is a delete you can trust. Remove the personal file from the shared folder and it is gone from the laptop you are about to sell, not lingering in a "deleted but recoverable" corner of someone else's cloud.

Check: on a scratch folder of your own, delete a synced file on one device and watch the other. Then ask where you would go to get it back. If the honest answer is "nowhere," you have understood this chapter — and you want chapter 6 before the folder holds anything you care about.