Exact same issue here.
And a big kudos and thank you to @Pixionus 's contributions on providing the log and helping Obsidian team to fix the bug.
Sorry, this was in reply to you, so reposting as such.
we have yet to see them take a single action…
I’m sitting here literally watching as Obsidian downloads gb of data I have deleted. Deleted the folder for the 3rd time… and watching it bring it all back…
F*cking ridiculous at this point, and still no word from @WhiteNoise or any of the devs.
Setting up my own sync service based on git at this point and sending out an advisory and apology to my colleagues regarding this (I’d told them there was an issue but that I thought the devs were working on it, but it’s been over 2 years since then, and for my own integrity I need to issue a retraction of endorsement, which is very embarrassing).
I shudder to think how many people I’ve roped into paying Obsidian money at this point 
I am sorry but while we believe this problem is real, we haven’t been able to reproduce it internally.
We use Obsidian as team vault and and use Obsidian for our personal notes and it hasn’t happened to us.
However, I do believe that this problem is real. I don’t know why some users experience it and other don’t. We are not sure what triggers this problem. We will keep investigation active.
As someone who works in the software industry and has had to debug issues exactly like this in synched databases in the past, the practice we lean on is good persistent logging and tombstone and other standard HA db practices. It appears you have neither, which is why it is happening AND why it is hard for you to reproduce.
and it’s still going… copying down stuff I have deleted from my vault over an hour ago…
Steps to reproduce
-
Device A (desktop) and Device B (Android mobile) both connected to Obsidian Sync
-
Device B goes offline (Obsidian closed / no network)
-
On Device A, delete or move files in the vault (standard vault reorganisation — moving files to new directories, renaming, deleting)
-
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.
I confirm this. Just bought a year subs to find out it doesn’t work as intended!
+1, same thing here, 3 iOS devices on my Obsidian Sync
So I deleted two folder trees through the file explorer while all devices were online, and then:
- one device reconnected and uploaded a bunch of empty folders that were long gone from the server, acting like it just created them
- the sync log literally showed it receiving every folder deletion (“Server pushed (folder) (deleted or renamed)”) and then re-uploading those same folders a few seconds later instead of just deleting them
- another device deleted one folder tree no problem but straight up refused the other one, so I had to go delete the folders by hand on each device to finally break the loop
So yeah, the deletions do arrive, they just don’t get applied locally for empty folders, and then the device pushes them back as new, which matches the missing tombstone theory from the OP exactly and it’s really annoying to delete it from every devices(((
Steps to reproduce
This was a one-time historical incident and I do not know how to reproduce it deterministically. The exact action that preceded the event is unknown, so the sequence below describes the observed setup and outcome rather than a confirmed trigger:
- Use an existing local vault on Windows that is connected to an Obsidian Sync remote vault.
- The vault contains the current folder structure and notes, while older material is retained separately as historical copies.
- At approximately 22:33:46 local time (Europe/Paris) on 17 September 2026, 15 historical folder roots appeared in the Windows vault. Their local directory creation timestamps were concentrated in the same second.
I cannot confirm from the available evidence whether the roots were introduced by a Sync event, a stale device, a restore, or a local file operation. I am reporting this because I need help identifying the source. I have preserved the old vault copies and audited the affected content.
Did you read and follow the Troubleshooting Guide ? Yes
I also preserved historical copies and compared the affected files with the current vault before deciding what to recover.
Expected result
The connected vault should retain its current folder structure and notes when syncing across devices. Historical folders that are no longer part of the current vault should not reappear without a clear indication of the source, such as a restore, conflict, or incoming change from a particular device. If an older local vault is responsible, I would expect a safe way to identify that device before its content is applied.
Actual result
Fifteen historical folder roots appeared in the Windows vault. Their CreationTime values were concentrated at 17 September 2026, 22:33:46 local time (Europe/Paris). The roots included folders named with _OLD and older structures such as imported Clippings, Google Keep, Notion, and attachment folders.
A file inventory found 2,598 files in those 15 roots and 4,820 files elsewhere in the vault (7,418 files total at the time of the later inventory). SHA-256 comparison found that 1,798 affected files had byte-identical copies outside the roots and 800 did not. Of 825 Markdown files in the affected roots, 771 had no byte-identical copy elsewhere. Subsequent content and metadata review showed that a different hash did not necessarily mean missing content; many notes had been changed, renamed, reformatted, or had different metadata.
The cause is still unknown. I did not find incident-time Sync logs that identify the device or operation responsible. The debug information pasted below was collected after recovery and its Sync log shows successful connections and “Fully synced”; it is not a log of the 17 September event.
Environment
SYSTEM INFO:
Obsidian version: 1.13.7
Installer version: 1.13.7
Operating system: Windows 10 Pro 10.0.19045
Login status: logged in
Language: en-GB
Catalyst license: none
Insider build toggle: off
SYNC INFO (current debug snapshot; collected after recovery):
Vault ID: [REDACTED FOR PUBLIC POST]
Host server: [REDACTED FOR PUBLIC POST]
Device name: [blank in debug info]
Encryption version: 3
Allowed file types: image, audio, pdf, video, unsupported
Allowed special types: app, appearance, appearance-data, hotkey, core-plugin, core-plugin-data
Ignored directories: [none listed]
Vault path: [REDACTED FOR PUBLIC POST]
Plugins: 23 enabled / 23 installed
Importer v3.1.3
Style Settings v1.0.9
Calendar v1.5.10
Dataview v0.5.68
DB Folder v3.5.1
Timestamp Notes v1.0.8
Clear Unused Images v1.1.1
Tag Wrangler v0.6.5
Handwritten Notes v1.4.0
MetaEdit v1.10.3
Multi Tag v0.10.0
Templater v2.25.0
QuickAdd v2.24.2
File Cooker v2.0.1
Excalidraw v2.27.2
Sort and Permute lines v0.8.0
Linter v1.32.0
Heading Shifter v1.15.0
Multi Properties v1.4.3
Mind Map v1.1.0
Line Arrange v1.7.0
Tag Tactician v1.10.2
TagFolder v0.18.21
Sync logs in this debug snapshot: successful connections and “Fully synced” on 1 October 2026. These are post-incident logs, not logs from 17 September.
Additional information
I preserved the old PC and mobile vault copies. I kept the iPad offline during the investigation, compared the old POCO vault against the cleaned PC vault, and reviewed same-path files with different contents. None of the 16 differing files needed to be replaced by the old mobile version. I then connected fresh local vaults on the POCO and iPad to the existing remote vault. The user-visible result on all three devices was “Fully synced”; I confirmed that the photographs display on mobile.
The content audit and recovery review were completed by 29 September 2026. More than ten hours were spent investigating and checking the files. The historical copies remain preserved. I would like help identifying which client or remote event introduced the folders and advice on safeguards for reconnecting devices that may contain stale vault data.
Available evidence: sanitized file inventories and SHA-256 comparison reports, a folder creation-time report, selected Sync log screenshots, and a decision register for the reviewed notes. I can provide the unredacted debug-info TXT and vault identifier privately by email if needed. I have not attached the raw debug-info file to this public-ready version because it includes a vault ID and local Windows path.