ob sync --continuous overwrites remote files with stale/empty local copies

[lance0]

Bug Report

Environment

• ob version: latest as of 2026-03-26
• Node.js: 22+
• OS: Ubuntu (headless server) + macOS (desktop)
• Sync plan: Active

Description

Running ob sync --continuous in bidirectional mode causes files to be overwritten with stale/empty local copies, resulting in data loss across all synced devices. Initially observed on a headless Linux server, but the root cause was traced to a macOS desktop device — the bug is in the shared sync engine.

Steps to Reproduce

1. Have a vault actively synced to Obsidian Sync from multiple devices
2. Edit or create files on one device — Sync pushes them to remote
3. Another device (running continuously) picks up the changes but re-uploads stale local copies, overwriting the valid remote content

Observed Behavior

Files oscillate between their correct content and 0 bytes (or frontmatter-only). The Obsidian Sync version history shows a clear pattern:

version 1:  0 B        (stale push)
version 2:  2.34 KB    (correct content)
version 3:  1.67 KB    (partial/frontmatter only — stale push)
version 4:  2.34 KB    (corrected)
version 5:  1.67 KB    (stale push again)
...repeating

Expected Behavior

After downloading a remote change, the sync engine should not re-upload the file it just downloaded.

Impact

Silent data loss. Files appear to save correctly but are quietly overwritten. Recovery is possible via version history, but only if caught in time.

Workaround

Use --mode pull-only on devices that don't need to push changes.

[lance0]

Update: Traced to the shared sync engine

The data loss in my case was coming from a macOS desktop device, not the headless server — identified by checking device IDs in Obsidian Sync version history. However, the issue persisted after switching the headless instance to pull-only, which points to a race condition in the sync engine itself.

What I found in the bundled source

There appears to be a race between syncFileDown and the OS file watcher:

1. syncFileDown writes a file via writeBinary, sets mtime via utimes, and updates the in-memory record with the correct hash and synchash
2. The file watcher's onFileChange fires asynchronously (setTimeout(..., 0)) and queues reconcileFile
3. The reconciliation compares Math.round(stat.mtimeMs) against the stored mtime. If they differ (rounding, timing), it triggers a "modified" event
4. The onChange("modified", ...) handler clears the hash: r.hash = ""
5. On the next sync cycle (30s interval), the upload logic sees m.hash && m.hash === g.hash fail (since hash is empty) and re-uploads the file

There's a justPushed/wasJustPushed guard that prevents echo-back on the server side, but no equivalent on the local filesystem side for files just written by syncFileDown.

pull-only and mirror-remote modes return before the upload loop runs, which is why they're not affected.

Workaround

--mode pull-only for devices that don't need to push.