I’m gonna be a little salty here, I apologize. I’ve run into some really frustrating defects on 0.9.20 but this defect will be the one that finally incentivizes me to move away from Logseq.
I ran into an issue where edits in Logseq are not getting written to the markdown files in the ./pages/ directory. And no backup data made it into ./pages/logseq/bak directory.
Here’s a screenshot of my edits in the Logseq app on MacOS:
Here’s a screenshot I took of the contents of the markdown page on my local drive immediately after I took the above screenshot. None of my edits are in the markdown page.
Thank you for doing the work looking into this. I have been having similar issues, and trying to keep working in Logseq with the data loss is beyond frustrating. I am hoping there will be some sort of official response to this.
If it helps, I downgraded to 0.9.19 and have not had this issue since. Seems likely it’s a defect in 0.9.20. That release was pretty problematic more for me.
I’ve encountered the same issue multiple times in the last weeks. At some point, the changes made in logseq get not written to the file anymore. A re-index or a restart leads then to the loss of everything written during a whole workday. Since there was nothing written to the actual files, the git integration had nothing to commit/save at this point.
I have a clean installation without sync activated for the affected graph. The only notable circumstance is that I’ve running multiple instances of Logseq with different graphs simultaneous.
In my opinion, this issue should get the highest priority since multiple user have reported similar problems. No new shiny features, just the very very basic functionality. So frustrating.
I just experienced a loss of about a month of important work daily notes, including the presentation I need for a customer meeting tomorrow. They were there before I turned off my computer to get to the customer. I am at an utter loss and can’t tell you how fucking screwed I am. I though doing nightly backups of my logseq directory was going to be enough but it hasn’t written the directory since the middle of July!!!
SO. MUCH. DATA. LOSS. Data like the time spent on projects so I know how much to bill.
I really liked Logseq, spent a lot of time moving over from Roam. But ANY dataloss is completely unacceptable. DO NOT USE LOGSEQ IF YOUR DATA IS IMPORTANT. So furious right now.
I was using demo.logseq.com. Wasn’t using github or sync or anything. Just pointing to a folder on my C drive.
Just got here after importing/ structuring a large document. When done, I restarted logseq and it asked me for which data I want to use, the one from disk or the logseq version. I picked the logseq version and good 2 h of editing are gone.
Logseq is a great idea, I binch watched youtube to learn more on it but common: It feels like the essential stuff isn’t working. I’ll stop using it. Too dangerous for me.
Back with Logseq for 2 weeks now, after a year of unsuccessfully searching for an alternative. Most of my problems could be solved with compromises. Then - after three days of intensive work on datalog queries and then enthusiastically importing 1400 markdown files - the first data loss. 3 hours of work were not written to the local file system.
I still can’t understand exactly what happened. I had made some changes via the pop-up windows on the page. Maybe this is one of the problems.
The problem with the many, really many reports of Logseq data loss is: There doesn’t seem to be any serious debugging of this problem anywhere. In any other project this would be the number one priority. How can you put all your energy into the database version if this bug hasn’t been dealt with anywhere near sufficiently? There are some indications that it is not an exclusive problem with the Logseq sync, but also occurs with local installations. Maybe many of the reported problems are sync problems. But the program also seems to have repeated problems writing its data from memory.
If none of the current developers are willing to find out what is going on here, then we should do it ourselves. At least do some thorough bug reporting and analyze these problems in detail.
Many of the reports lack precise information about: “sync method used”, “how was Logsynq used”, how was the computer loaded, load problems etc.", “antivirus programs or similar that used the graph folder” “error messages from the dev consolee”, “the use of re-index while operating on your files” etc.
Without this knowledge, it feels a bit esoteric to what is happening here and it is very difficult to trust this program because there are so many reports and it is not sure if anyone is working on this beside the db version (which wil not be the solution for many passionate logseq users)
Wow didn’t know that. I just keep using the sidebar.
I am really not sure about why some people are experiencing data-loss but I thought to share my setup to just see if it helps anyone (I just create plugins for Logseq, but am not part of the development team).
I use Logseq Sync to sync across 2 Macs, 1 iPad and 1 iPhone. I sometimes have more than 1 device opening Logseq at a time.
I don’t use the browser version and only the desktop version on my Mac.
I have my vault stored in a directory that is not synced with any other directory, device or network (just an isolated directory on my computers).
I back the vault up using Time Machine, but don’t use rsync, etc to sync it.
I don’t use git to track changes or automatically push it anywhere.
I don’t use multiple Logseq windows on a single device.
I have many many plugins installed at any one time.
Do feel free to ignore if the above doesn’t apply to you or you feel that it constrains your workflow in some way. I do believe everyone has a right to choose a tool that fits them rather than the other way around.
This is the first time I had those issues.
And I was a bit afraid to see all the other complains.
After deeply reflecting what could have caused this issue - I would assume one (or multiple) of the following:
Sync feature (maybe in combination with something else)
After importing all of my text files I had a significant load on my machine. Not sure what triggered it
could also have been some other programm (worked on my companies notebook where there has to be a running clamav instance for policy reasons. This sometimes could slow my machine down)
I had to do several re-indixing jobs of the files. Maybe this in combination with the memory load killed the “write to file” process.
I also used the inline editing as described. I saw that some one else mentioned it before regarding the data loss issues.
Anyway - I really want to stay with logseq as there is no well functional alternative for me (expect of Emacs/Roam). But in Emacs I am missing the outline feeling a bit (although it is a outliner with org-mode, but it is not the same visual experience. And the compromises which I have to make to get a better mobile experience are also not the same.
I will stay with logseq and having an eye on this subject and also try to learn some clojure (what was on my backlog anyway) to get a better understanding how I could prevent those issues in the future.
Hopefully it just had been a rare race condition in that case.
