If a page is edited when not fully synced, the new changes might overwrite the remote contents that not synced to local
mostly happens when switched to a new device, launch Logseq, and edit pages without waiting the icon on the top-right to become .
another case is using quick capture on mobile platform and it edit contents without waiting (it’s a bug under fix)
It’s because that Logseq Sync is currently using a “newer first” strategy on the file timestamps. The edit on the new device has a newer timestamp, while the remote content isn’t synced to the new device yet.
To recover the overwritten data, may check these on ALL of your devices:
The page history feature in Logseq
The recycle directory for recent deleted / overwritten files in <graph directory>/logseq/bak
We are discussing the sync resolution combining text & db structure on Discord Thread
Feb 15 2023 update:
We just have some break-through on sync conflict resolution, and some kinda implicit “universal block uuid preservation” unifying db & text files, while keeping robustness to external (offline) editing. It is a block-granulation resolving.
Hopefully we can ship it to the production environment soon, and the multi-device editing experience & robustness would be significantly improved.
This is a case where logseq must be very careful to manage conflicts.
If local copy is changed before server version has been synced the system MUST recognise this as a conflict and either resolve the conflict automatically (if possible) or alert the user about the conflict and let her solve it herself before continuing.
As an outliner, it seems clear that Logseq should not consider files the atomic unit of updates, but rather items/lines. This is one of the biggest reasons to build a custom sync engine rather than relying on a generic file sync service in the first place.
At minimum I would expect line-level merge; more ideal would be an actual structural diff and merge on the outline data structure (including recognizing when a node has been changed/indented/etc. as a relative edit that correspondingly affects the rest of the subtree, not a raw line-level text diff on the Markdown or Org representation).
I think JRK has exactly the right framing of this problem-solution.
To add on, I find the version history UI basically doesn’t work very well:
I often can’t scroll through the histories
I wish there was a proper visual diff like in Github, because when there have been many edits I dread having to look through all the versions to try and figure out the difference by myself
We just have some break-through on sync conflict resolution, and some kinda implicit “universal block uuid preservation” unifying db & text files, while keeping robustness to external (offline) editing. It is a block-granulation resolving.
Hopefully we can ship it to the production environment soon, and the multi-device editing experience & robustness would be significantly improved.
Fantastic to hear. I’m really glad you all are taking this very seriously and from your descriptions here and on Trello it sounds like you very much have your heads on straight about how to do it. Retaining the ability to allow external edits of the text representation in the filesystem is even better.
My sync issues come from the annoying logout timing on Logseq. The 14 day limit appears to be more random, so this morning i worked on macbook in LS syncing ok. I later noticed my imac version had logged out. When i logged in, the imac journal for today overwrote all the work i did on the macbook.
icon on the top-right to become 
.
Retaining the ability to allow external edits of the text representation in the filesystem is even better.