I've lost all the notes of a pdf after PC hard reset

[All3xJ]

Operating System

Linux

(Linux only) Distribution

Fedora

(Linux only) Desktop Environment

GNOME

(Linux Only) Display Server

Wayland

Installation Method

Flatpak

Xournal++ Version

1.2.3

libgtk Version

3.24.41

Bug Description

I had a xopp file (some KB of data) in which I worked on since days.
I was adding some notes to it, but my laptop auto hard reset itself. When I power on again, I suprisingly found that my xopp file wasn't opening, then I realized that it was 0 bytes..... all was gone. It's strange, it never happened to me. I don't understand why even the previous notes in xopp file are gone. I understand that the notes that I haven't saved are not there, but here everything is GONE. Also the .autosave is 0 bytes.

I've also checked in /home/user/.var/app/com.github.xournalpp.xournalpp/cache/xournalpp/autosaves folder, but there is no a autosave for my pdf xopp there.

Expected Behaviour

I shouldn't have lost ALL THE NOTES of that xopp file, but only the non-saved notes of that xopp.

Steps to Reproduce

1. Open an existing xopp file
2. So some edits
3. Hard reset (actually, it happened other times that my PC auto hard-reset, but I've NEVER lose anything)

Additional Context

Is there any other place I can check? Is it everything gone for ever?
To decrease the possibility that this happens again, should I increase the autosave minutes interval? Or should I decrease it to the minimum? I think I should increase it from 3 to 5 because I guess that this problem was given by the fact that laptop auto hard-reset at the same time that it was saving. Can this be right? What you think? The strange thing is that both .autosave and .xopp files are 0 bytes.....

[rolandlo]

I'm sad this happened and deeply sorry for you. It's curious how this was possible. We have quite some safety measurements in the code.

Can you also check whether there is a file named file.xopp~ in the same folder as the original file (whose filename I assume to be file.xopp)? When Xournal++ tries to save a file, it first renames the target (file.xopp) to file.xopp~. Only if saving has finished without errors it removes the file.xopp~ file again.

There could also be a file.autosave.xopp.swap file or a file.autosave.xopp~ file from autosaving. During autosave the previous autosave file is first left untouched and the new autosave file is created as file.autosave.xopp~. If that was successful, the original autosave file file.autosave.xopp is renamed to file.autosave.xopp.swap, the newly created file.autosave.xopp~ is renamed to file.autosave.xopp and only then is the file.autosave.swap deleted.

If none of these files are present, the most likely scenario seems to be that Xournal++ finished saving and autosaving without error messages and falsely believed that everything went fine. It's hard to image this is possible (and also seems unlikely on a hard reset), but we should not rule out that possibility.

[All3xJ]

Can you also check whether there is a file named file.xopp~ in the same folder as the original file (whose filename I assume to be file.xopp)?
There could also be a file.autosave.xopp.swap file or a file.autosave.xopp~ file from autosaving.

thanks for your help, but unfortunately no such file is in my directory. just the .xopp and .autosave.xopp both of 0 bytes

[rolandlo]

Do you have a reproducible way to get a "PC hard reset"? From the code I don't understand how it is possible that a 0-byte file is written, but if it is reproducible in some way I can debug the problem and try to fix it.

[rolandlo]

I can crash the process in which xournalpp is running using

kill -SIGKILL $(pidof xournalpp)

Doing so while Xournal++ is in the process of saving the file (which may take a while if you put lots of images into it), I get a corrupted file.xopp but a working file.xopp~ (and no emergencysave.xopp in the config folder from which to restore), e.g. like this:

I don't see how a hard system crash instead of a process crash would change that.

Can you please make sure once more that there is no HIDDEN file file.xopp~ in the same directory as file.xopp and that you run version 1.2.3 indeed?

Can you also try to kill the xournalpp process as above when saving an unimportant (but large and previously saved) xopp-file and see if you have a file.xopp~ in the same directory?

[All3xJ]

Ok I did what you said. I killed with kill -SIGKILL $(pidof xournalpp) while a large save was being performed. Two files are effectively created: the .autosave.xopp and the .xopp~ so it appears to work. So I really don't know what happened in my case. What else can I do to investigate?

Is there any situation in which xournalpp erases the .xopp file in some case? Maybe if some particular xopp read or write does not succeed? I really don't know what to think.

I also did a:

$ journalctl --since 2024-05-05 > cxournalpp 
$ cat cxournalpp | grep xournalpp | grep -E 'error|warning|problem|issue|critical|alert|exception|failure|fatal|crash|bug|save|autosave|stack|trace|coredump|corrupted|file|not|data|loss|conflict|can.t' | grep -E 'May 05|May 06'

and this is what I get, I don't know if any of this is useful:

May 06 22:35:15 fedora xournalpp[82535]: Autosaving to /home/allexj/Desktop/Wireless Security/teoria/.9 - WiFi security.autosave.xopp
May 06 22:38:15 fedora xournalpp[82535]: Autosaving to /home/allexj/Desktop/Wireless Security/teoria/.9 - WiFi security.autosave.xopp
May 06 22:41:15 fedora xournalpp[82535]: Autosaving to /home/allexj/Desktop/Wireless Security/teoria/.9 - WiFi security.autosave.xopp
May 06 22:44:54 fedora com.github.xournalpp.xournalpp.desktop[5950]: ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
May 06 22:44:54 fedora com.github.xournalpp.xournalpp.desktop[5950]: ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
May 06 22:47:25 fedora com.github.xournalpp.xournalpp.desktop[6630]: ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
May 06 22:47:25 fedora com.github.xournalpp.xournalpp.desktop[6630]: ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
May 06 22:52:11 fedora com.github.xournalpp.xournalpp.desktop[7588]: ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
May 06 22:52:11 fedora com.github.xournalpp.xournalpp.desktop[7588]: ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
May 06 22:59:11 fedora com.github.xournalpp.xournalpp.desktop[9010]: ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
May 06 22:59:11 fedora com.github.xournalpp.xournalpp.desktop[9010]: ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
May 06 22:59:11 fedora xournalpp[9010]: Cannot update zoomPresentationValue yet. This should only happen on startup! 
May 06 22:59:34 fedora com.github.xournalpp.xournalpp.desktop[9088]: ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
May 06 22:59:34 fedora com.github.xournalpp.xournalpp.desktop[9088]: ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
May 06 23:04:48 fedora xournalpp[7588]: file:

but I compared them to other journalctl xournalpp logs, and they seem fine to me: they are pretty common log rows.
Do you want me to check for other keywords?

EDIT:
I thought: can it be a filesystem issue? I'm using BTRFS and I found this and this posts.

[bhennion]

I thought: can it be a filesystem issue? I'm using BTRFS and I found this and this posts.

It most likely is. Hard reset very often lead to data loss. I'm gonna close this, as we can't really do anything against critical system failures.