Data loss on my very first real journal entry

Feedback Bug Reports
1

iCloud sync led to data loss on a journal entry I edited on my iPhone and iPad a few hours apart. Started on my iPad, later on added a bullet on phone, then when I went to look again on iPad the bullet was gone. Went back to phone and saw it there for a split second before it vanished.

This was the first time I tried to use LogSeq for real, keeping track of my daily thoughts and activities. My confidence is hanging on by a thread at this point. Is this problem understood? Is there a plan to address it? Is there a reliable workaround or solution?

2

Based on unreliable data, here is the current:

  • reliability score of:
    • Logseq without sync: 99.84%
    • Sync with one instance open at a time: 96%
    • Sync with multiple instances open: 0.8%
      • This is your case.
  • hope for sync: coming database version
  • trend among users needing sync: third-party sync solutions
    • Search in the forums for a variety of them.
3 Likes
3

Thanks for replying. In that case, given that iOS is not a system where “having an instance open” is a well-defined thing, why is there an “iCloud Sync” switch at all for new users to naively turn on? Shouldn’t there be a prominent warning if you do turn it on?

2 Likes
4

Oh wow, where did those numbers come from?
Is there some way for the Logseq people to track that “reliability”, whatever that means, while keeping it secret?
… or did you just pull out those stats from… thin air?

5
  • Logseq:
    • has a very diverse userbase
      • targets multiple platforms
      • releases new versions frequently
    • is beta software at best
      • Every version introduces bugs.
        • That includes bugs which affect reliability.
  • Keeping serious stats in such conditions is practically impossible.
    • That doesn’t stop anyone from gathering some stats for whatever it’s worth.
      • I have labeled mine unreliable since the beginning.
        • They have all kinds of assumptions and rounding.
        • They utilize a narrow definition of reliability.
      • Nobody should take such stats seriously.
        • And arguably any stats about anything.
          • It has long been observed that stats are the superlative of lies.
  • None of the above is a secret.
  • I neither need nor plan to share actual data.
    • Among other reasons, not to feed a pointless discussion.
  • I’m not “Logseq people”.
    • Whatever that means.
6

Ah, I didn’t know that “unreliable” means “totally made up”. Sorry, got it now.

I guess that’s why the sync is unreliable, right?
Ba-dum-tsss!

7

What I gather is an effort of projecting your own habit of making up things.

  • You are free to believe your own wild guesses and oversimplified generalizations.
    • In a black-or-white world, you could even be right.
    • But in the real world, Sync works.
      • Neither reliably nor in an always-or-never fashion.
      • It works in most scenarios and for the most part.
        • This is obviously irrelevant for the remaining scenarios.
        • Even for the working scenarios, it is not enough for anything critical.
          • This is true for any beta software.
        • The number of open instances makes a difference.
          • Statistics happen to support that.
            • With a big drop between 1 and 2.
            • That’s not of much value.
              • Statistics are never of much value.
              • And yet it has more value than every aggressive post combined.
8

From my experience this is not a Logseq issue but rather an Apple iCloud issue. I encountered similar issues with other software too and now try to avoid it for sync altogether. If you need reliable sync with ability to recover conflicts nothing beats git in my opinion. Also syncthing works well for me but there I also try to make sure to edit stuff only on one device at a time as @mentaloid suggested as well.

1 Like