Troubleshooting
Vault isn’t syncing
Triage, repair, and conflict resolution for each sync path: Git / iCloud / Dropbox.
Symptom
You edit on machine A and machine B does not see the change; or B shows a hours-old version; or both machines have content but they have diverged (you see "fight files" like note (conflict-2026-06-07).md).
Kition is local-first — it treats notes as plain Markdown files, and the sync is not done by Kition. Git / iCloud / Dropbox underneath do the moving. So the triage flow is: confirm Kition wrote to disk, confirm the sync tool moved the file, then confirm the other end pulled it back.
Common first step: confirm Kition wrote to disk
Kition autosaves every ~800ms by default, but the write can fail if the battery is critical, the disk is full, or another process holds the file lock.
# In your vault root, see the most recently changed files
ls -lt | head -20
# Confirm the file size > 0 and mtime is in the last minute
stat "Daily/2026-06-07.md"
# macOS: see if anything is holding the file open
lsof | grep "2026-06-07.md"Git sync triage
Git sync is the most transparent and controllable path — git status shows everything.
git status— check for staged / unstaged changesgit pull --rebase— fetch remote, replay your local on topgit log --oneline -10— confirm the other machine’s commits actually exist- Open conflict files in the editor, remove the
<<<<<<<markers, thengit add+git commit - Settings → Sync → check the auto-push interval (default is 5 minutes)
iCloud / Dropbox triage
Both are background filesystem services — Kition writes a .md, the iCloudDrive / Dropbox daemon pushes it up. Any sync problem is reflected in the daemon’s status.
- Look at the small icon next to the filename in Finder: cloud + arrow = uploading, green check = synced, red exclamation = failed
- Click the iCloud / Dropbox tray icon and scan the "recent activity" list for errors
- Open the cloud console (iCloud.com, dropbox.com), navigate to your vault path, confirm the remote actually has it
- Conflict file naming:
filename (conflict-...).md,filename (Bob’s MacBook).md— these come from the sync tool, not Kition - Never mount two cloud clients on the same directory — they will fight and overwrite each other
Dealing with conflict files
When you see something like Note (conflict-2026-06-07-093012).md, do not just delete it — that file is another version the sync tool rescued. Correct flow:
- Open the original
Note.mdin Kition - Open the conflict file in a plain text editor (or another Kition window)
- Diff section by section and merge the right content into
Note.md - Save, then delete the conflict file
- Strongly recommended:
cp Note*.md /tmp/first as a backup
Workaround
If you urgently need A’s latest content on B and normal sync is stuck: copy the entire vault directory across via rsync / scp / a USB drive, overwriting B’s old vault. Kition will rebuild the index on next launch (5-30s).
When to file a bug
- Kition saved but the sync tool never noticed (mtime did not change)
- After index rebuild, all wikilinks / backlinks vanish
.kitablefiles share the same mtime on both machines but differ in row count / checksum (data fork)