My iPad Wiped 25,743 Files in Two Minutes

At 12:40 PM on Saturday, my iPad connected to the Mac Mini via Syncthing. Its folder index was corrupted — it reported zero files. The Mac’s sendreceive mode accepted this as authoritative truth and started deleting.

By 12:42 PM, 25,743 files were gone. The entire Cerebro vault — every daily note, every project file, every piece of writing from the past year. 4.96 GB, gone in under two minutes.

I didn’t find out until Sunday morning.

The Discovery

I opened Obsidian on the Mac Mini and the vault was empty. Not “loading” empty — structurally empty. Just .obsidian and .stfolder. Everything else was gone.

I checked the MacBook Air (Dante). Its copy was intact — 25,743 files, all present. So the destruction was limited to the Mac Mini. That narrowed the timeline: whatever happened, it happened after the last successful sync between the two machines and before now.

The Forensic Timeline

Syncthing logs everything. That’s one of its best qualities and, on days like this, one of its most useful. I pulled the Mac Mini’s logs and found the whole story compressed into a ninety-second window.

12:40:12 — Device PQAF6PA (iPad) connected. Routine. Devices connect and disconnect all day as they move between networks.

12:40:14 — Cluster config exchanged. This is where Syncthing devices tell each other what they have. The iPad’s folder index was corrupted. It reported zero files in the Cerebro folder. Not “I haven’t scanned yet” — zero files. An empty folder. A clean slate.

12:40:14 to 12:41:30 — The Mac Mini’s sendreceive folder mode processed the iPad’s state and decided to converge. “The iPad says it has zero files. I have 25,743 files. We need to match. I’ll delete mine.”

12:41:30 — Mass deletion begins. Files removed in bulk. No per-file confirmation. No threshold check. No “you are about to delete 99.99% of this folder, are you sure?”

12:42:XX — Deletion complete. 25,743 files removed. 4.96 GB freed. The Mac Mini and the iPad now agree: the vault is empty. Sync achieved.

The whole thing — connection, negotiation, destruction — took less time than it takes to make a cup of tea.

Why This Happened

The iPad was running MobiusSync, a third-party Syncthing client for iOS. At some point — I don’t know when, and the iPad’s logs weren’t helpful — MobiusSync reset its folder database. Maybe a crash. Maybe a storage pressure event. Maybe iOS killed the background process at exactly the wrong moment. The cause doesn’t matter as much as the consequence: the iPad genuinely believed the vault was empty.

Syncthing’s protocol works on trust. If a device says “this is the current state of my files,” the other devices converge toward that state. There’s no concept of “that seems wrong” or “let me double-check.” An empty folder is a valid state. You might have intentionally deleted everything. Syncthing doesn’t judge intent. It synchronizes state.

What I expected: The iPad connects, notices it’s missing 25,743 files, and downloads them from the Mac Mini.

What Syncthing did: The iPad connects, reports zero files as its authoritative state, and the Mac Mini deletes its own files to match.

The difference between those two outcomes is entirely about which device Syncthing treats as the source of truth. In sendreceive mode, the answer is “whichever device spoke last.” The iPad spoke last.

The Recovery

Time Machine saved me. This is the part where I say something grateful about automated local backups and mean every word of it. The most recent Mac Mini snapshot was from 11:08 AM — about ninety minutes before the wipe. Close enough. I’d lose whatever I’d written between 11:08 AM and 12:40 PM, which on a Saturday was approximately nothing.

I restored using tmutil, verified the file count against the MacBook Air (Dante), and confirmed both machines had matching counts. The Mac Mini’s backup was slightly more current (it had Saturday’s daily note started), so it became the source of truth for the re-sync.

# 1. Find the most recent Time Machine backup
tmutil listbackups | tail -1

# 2. Restore the vault directory from the snapshot
tmutil restore \
  "/Volumes/TimeMachine/Backups.backupdb/opus/2026-03-01-110847/Macintosh HD/Users/deploy/Sync/Cerebro" \
  "/Users/deploy/Sync/Cerebro_restored"

# 3. Verify file count matches known-good device (Dante)
find /Users/deploy/Sync/Cerebro_restored -type f | wc -l
# Expected: 25743

# 4. Remove the empty vault and replace with restored copy
rm -rf /Users/deploy/Sync/Cerebro
mv /Users/deploy/Sync/Cerebro_restored /Users/deploy/Sync/Cerebro

# 5. Reset Syncthing folder indexes on this device
# (Forces a full rescan rather than trying to reconcile with the corrupted state)
syncthing cli operations resetfolder cerebro

# 6. Restart Syncthing and watch the rescan
systemctl --user restart syncthing
journalctl --user -u syncthing -f
# Watch for: "Ready to synchronize" with correct file count

Then I reset Syncthing’s folder indexes on both machines, restarted the service, and watched the rescan complete: 25,742 files indexed, zero errors. (The one-file discrepancy was a .DS_Store that Time Machine had excluded. I can live with that.)

What I Changed

Immediate: Disabled MobiusSync on the iPad entirely. The iPad was the attack vector and I don’t understand why its index corrupted. Until I do, it stays disconnected. I don’t debug the gun while it’s pointed at the vault.

Permanent: Added ignoreDelete to the vault’s Syncthing folder configuration on the Mac Mini. This is the architectural fix — it tells Syncthing to ignore deletion events from remote devices. If any connected device says “delete these files,” the Mac will refuse. Files can still be added and modified across all devices, but mass deletion from a remote device is now structurally impossible.

<folder id="cerebro" label="Cerebro" path="/Users/deploy/Sync/Cerebro"
        type="sendreceive" ignoreDelete="true">
    <!-- ... devices, versioning, etc. -->
</folder>

Before settling on ignoreDelete, I mapped out the three options:

ignoreDelete is the narrowest fix. It blocks exactly the failure mode that burned me — a remote device propagating mass deletion — without restricting normal bidirectional sync for additions and modifications. The MacBook Air and Mac Mini can still share new files and edits freely. The only thing that changes is that “Device X says delete everything” no longer results in everything being deleted.

Insurance: Kept the Cerebro_restored backup directory for a week, just in case the restored vault had subtle corruption that wouldn’t surface immediately.

The Pattern

This is the classic bidirectional sync disaster. Every Syncthing user who’s been around long enough has a version of this story. The failure mode is always the same: a device with corrupted state becomes authoritative and propagates destruction to healthy nodes. The protocol is doing its job. The job just doesn’t include “be suspicious of dramatic state changes.”

The mitigation is also always the same: don’t trust deletion events from remote devices, and keep offline backups that sync can’t touch. Time Machine runs on a local USB drive. Syncthing can’t reach it. iCloud can’t reach it. No sync protocol, no cloud service, no network-connected device can modify those snapshots. That’s the point.

What surprised me was how fast it happened. Two minutes. No warning, no confirmation dialog, no “are you sure you want to delete 25,743 files?” Syncthing did exactly what it was designed to do. The design just doesn’t account for a device lying about its state.

Syncthing trusts every device equally. There’s no concept of a “primary” node whose state takes precedence. There’s no quorum — two devices agreeing don’t outvote one device disagreeing. Each connection is a bilateral negotiation, and in sendreceive mode, both sides are equally authoritative. That works beautifully right up until one side has brain damage and doesn’t know it.

The fix isn’t to abandon bidirectional sync. It’s to add asymmetric trust. My Mac Mini — the machine with the Time Machine backup, the machine that’s always on, the machine that holds the canonical copy — should trust itself more than it trusts incoming state from mobile devices with flaky third-party sync clients. ignoreDelete encodes that asymmetry. It says: “I’ll believe you when you say you have new things. I won’t believe you when you say I should destroy mine.”

That feels like the right default for any system where the cost of false deletion vastly exceeds the cost of a stale file hanging around.