Sync deletion propagation: why it should be off by default

7 October 2026

Deletion propagation is the part of folder sync that turns a copying tool into a destructive one. With it on, deleting a file on one side deletes it on the other. With it off, sync only ever adds and updates files. Off is the right default, because a sync tool can't tell from the two folders alone whether a missing file was deleted on purpose, and the cost of guessing wrong is losing data on both sides at once. This post explains why, and how to use sync deletion propagation safely when you do want it.

A missing file is ambiguous

Imagine a local folder and a server folder that have been kept in step. You run a sync, and report.pdf exists on the server but not locally. There are two possible stories:

1. You deleted it locally, and want the server copy gone too.
2. Someone added it on the server, and you want a local copy.

The two folders look identical in both cases. Nothing in the current state distinguishes "deleted here" from "new there". A two-way sync that wants to propagate deletions needs a third input: a record of what existed on both sides after the previous sync. With that baseline, the rule is clear. If a file was present on both sides last time and is now missing from one, it was deleted there. If it wasn't in the baseline, it's new.

Why the first run can't detect deletions

That baseline has to come from somewhere. On the very first sync between two folders there is no previous state, so every missing file has to be treated as new and copied across. A tool that claimed to propagate deletions on a first run would be guessing, and the obvious guess (mirror one side onto the other) is the dangerous one.

One-way mirroring has the same problem in a different shape

One-way tools avoid the ambiguity by declaring one side authoritative: whatever isn't in the source gets removed from the destination. The AWS CLI's sync command works this way when you add --delete:

aws s3 sync ./public s3://example-site --delete --dryrun

That is predictable, but it moves the risk rather than removing it. The command trusts the source completely, so anything wrong with the source is copied faithfully to the destination:

• A typo in the source path that points at an empty or wrong folder.
• An external drive that wasn't mounted, so the path resolves to an empty mount point.
• A build step that failed halfway and left an output folder with a third of the files.
• A .gitignore-style exclusion that left out a directory you meant to keep on the server.

Every one of those becomes a mass deletion on the destination. The --dryrun flag exists for exactly this reason, and it's worth using every time.

What safe deletion propagation looks like

If you do want deletions mirrored, the safeguards are the same regardless of tool:

• Opt in explicitly, so that nobody gets destructive behaviour they didn't choose.
• Show the list first. A dry run or review step that names every file to be deleted catches the empty-source mistakes above, because the list is suddenly enormous.
• Make local deletions recoverable. Moving to the Trash costs nothing and turns a mistake into an inconvenience.
• Protect the remote side separately. There's no Trash on an SFTP server. For S3, turn on bucket versioning, so a deleted object leaves a previous version behind. For servers, keep backups that don't sync.
• Keep a record. When something disappears, being able to see which sync removed it, and when, shortens the investigation.

How Wharf handles sync deletion propagation

Wharf's sync is a two-way comparison that, by default, never deletes anything. A file missing from one side is copied to it. The review sheet says so in plain words: "Files removed on one side will be copied back from the other."

To mirror deletions, tick Also delete files removed on the other side in the sync review sheet. Wharf then re-plans straight away, and any files it would remove appear in their own section, Will be deleted, marked "to Trash" for local files and "on server" for remote ones, before you click Start Sync. The caption beneath the toggle states the consequences: local files go to the Trash, and files on the server are removed permanently.

Deletion detection works from a baseline, as described above. Wharf records which files existed on both sides at the end of each sync pass while the site is open, and compares the next pass against it. On a first pass there's nothing to compare against, and the review sheet tells you so: nothing can be identified as deleted yet, and deletions apply from the next check onwards. The support page covers this under "Sync didn't delete anything".

A few other details follow from the same principle:

• Conflicts aren't settled by deleting. A file changed on both sides is shown with both sizes and dates, the newer copy is pre-selected, and files whose timestamps are too close to call default to Skip.
• Deletions are visible. They run through the Transfers list like any upload, shown with a warning tint, and land in the activity log as "Deleted on server" or "Deleted locally".
• Continuous sync is explicit about it. If you start Keep in Sync with deletions turned on, the activity log notes that continuous sync started with deletions propagating. Later cycles then apply deletions without another review, which is what continuous mode means, so turn it on only for a pair of folders you trust.
• Automations never delete. The Shortcuts action Sync Folder copies whatever is missing on either side and never propagates deletions, because a scheduled job has no review step. The Shortcuts guide covers it.

The sync section of the homepage shows the review step, and the two-way sync walkthrough goes through a full run.

A checklist before you turn deletions on

1. Run the sync once without deletions, so both sides match and a baseline exists.
2. Check the source folder is the one you think it is, and that any drive it lives on is mounted.
3. Turn on deletions and read the list of files to be removed. If it's longer than you expected, stop.
4. Make sure the server side has a backup or, for S3, versioning. See the S3 versioning documentation.
5. After the run, check the activity log for the deletions it recorded.

Deletion propagation is useful: without it, files you've removed keep coming back. It just needs to be a decision you make with the list in front of you, rather than a default you discover the hard way.