Obsidian Sync silently resurrects deleted/moved files when offline device reconnects

Bug reports
1

Steps to reproduce

  1. Device A (desktop) and Device B (Android mobile) both connected to Obsidian Sync

  2. Device B goes offline (Obsidian closed / no network)

  3. On Device A, delete or move files in the vault (standard vault reorganisation — moving files to new directories, renaming, deleting)

  4. Device B comes back online and opens Obsidian

Did you follow the troubleshooting guide?

Yes. This is not a theme or plugin issue — it affects core Sync behaviour with no community plugins involved. Reproduced with default theme.

Note on packaging: Device A runs the Flatpak build, not AppImage or Snap. However, this bug is in the Sync service’s deletion propagation logic, not in the desktop app’s rendering or local file handling. The packaging format does not affect how the Sync server processes deletions from reconnecting devices — Device B (Android) is the device that re-uploads the ghost files, and Device A is simply the recipient.

Syncthing also runs on Device A for backup to a NAS, but does not sync to Device B. Device B uses Obsidian Sync exclusively. The ghost files originate from Device B via Obsidian Sync — Syncthing is not involved.

Expected result

Device B receives the deletions/moves from Device A. Deleted files stay deleted. Moved files exist only at their new paths.

Actual result

Device B re-uploads its locally-cached copies of the deleted/moved files. ~80 previously-deleted .md files reappeared across the vault:

  • Files that had been moved on Device A reappeared at their old paths, creating duplicates

  • Files that had been deleted on Device A reappeared as if never deleted

  • Ghost files spanned many directories, from 5+ distinct reorganisation events across the offline period

  • This affects any offline duration — not just extended periods. If Device B is offline for one hour while Device A deletes a file, the file reappears when Device B reconnects.

Key observation: Files that were modified on both sides correctly triggered conflict files ((Conflicted copy ...)). Conflict detection works for modifications. But deletions are not treated as a “side” in the conflict model — if a file exists locally and does not exist remotely, Sync treats it as a new local creation and uploads it, rather than recognising a conflict between “exists locally” and “was deleted remotely.”

Environment

  • Obsidian: v1.12.7 (installer v1.12.7, Flatpak)

  • OS: Ubuntu 25.10, Linux 6.19.4, x86_64 (Kubuntu/KDE Plasma)

  • Sync: Obsidian Sync, Standard plan

  • No Catalyst licence

  • Theme: default

  • Community plugins (7): Templater, Git, Kanban, Importer, Recent Files, Local REST API, Hotkeys for templates

  • Device A: Linux desktop (above)

  • Device B: Android mobile

  • Offline duration: ~4 weeks (but duration is irrelevant — the mechanism fires for any offline period during which a deletion occurs)

  • Ghost files: ~80 across 5+ reorganisation events

Additional information

Forensic confirmation: The vault uses git-based auto-save commits, which allowed post-hoc verification of every ghost file:

  • Every ghost file had a corresponding deletion commit during the offline window

  • Every moved file had a newer counterpart at its current path — the ghost was the stale copy at the old path

  • No ghost file was a legitimate local creation — 100% were stale cached copies of previously-deleted content

  • Ghost files came from 5+ separate reorganisation events, confirming this is systematic, not a one-off race condition

Why existing settings don’t help:

  • “Keep the latest file by modification time” — ghost files have old modification times, but they aren’t detected as conflicts because there’s nothing at that path to conflict with

  • Deleted files recovery — this is about intentional recovery from version history, not about preventing ghost resurrection

  • Selective sync / excluded folders — doesn’t help; the ghosts span the entire vault

Related threads:

Both threads describe the same issue. This report adds forensic confirmation (via git history) that the mechanism is the absence of deletion tracking for offline devices, not a plugin conflict or user error.

Proposed root cause: Sync appears to have no durable deletion log (tombstones) for late-arriving devices. When Device B reconnects and finds a local file with no remote counterpart, it assumes the file is a new local creation and uploads it. Remote deletions are indistinguishable from “file never existed remotely.” Any device offline during a deletion or move will undo that change on reconnection.

Proposed fix: A durable deletion log recording file path + timestamp, retained for a configurable period (e.g. 90 days). On reconnect, Sync checks: “Was this path deleted on the remote after the device’s last sync timestamp?” If yes, delete the local copy (or flag as conflict) instead of uploading it.

1 Like