Recovery dialogue every day

Well this has been happening across several Linux distros I’ve used, for as long as I’ve been using LibreOffice (about 5 years), and I decided to ask about it;

Unless I remember to close all my documents before shutting down, I will be seeing the LibreOffice “document recovery” dialogue the next morning as soon as I open my first document.

I don’t ever leave any unsaved changes, this seems to be a result of LibreOffice being shut down in a way that it doesn’t close the little data files that it creates when a document is opened. So it thinks a crash has happened, every time.

I don’t know if the OS or LibreOffice is to blame here, but one of them has to take responsibility for this, because if I’ve saved all my changes and shut down the computer, no recovery should be necessary.

The danger here is a “boy who cried wolf” situation is being created, where I’m getting used to ignoring the “Document Recovery” dialogue and skipping out of it every time, until one day where perhaps it’s legitimate and there really are unsaved changes due to a crash, and I skip over it. Never happened so far, I would be pretty concerned about recovering documents if the power suddenly cut or the computer crashed, but still…

Is there a way to get the OS shut down sequence and LibreOffice to play nice with each other so that this dialogue doesn’t pop up every morning? My current OS is Endeavour OS, but prior to this I’ve used Manjaro, MX Linux, Ubuntu, and Linux Mint, all with the same result.

Well, I think the system is quite simple.
Every time you open a file, LibreOffice creates a so-called “lock” file. Example: .-lock.FILENAME.odt#
for an ODT file. This “lock” file is removed again when you close the document.
If the file is not closed carefully, this “lock” file remains and LibreOffice sees that it was not closed properly the next time it is opened.
LibreOffice cannot distinguish the reason why the file was not closed properly.

See also:

If you are not satisfied with my answer, you can submit a change proposal on Bugzilla.

1 Like

@Hrbrgr But the thing is, LibreOffice is the only program I have to remember to shut down manually to avoid it thinking there was a crash. Other programs will close gracefully with a shut down, and only bring up a “recover files” dialogue if there really was an improper program termination (which you could trigger by force quitting the program, for example).

So I was just wondering; is there a way to get LibreOffice and operating system shutdown to play nicer with each other?

I don’t think so, but I’m not a developer or system expert either.

As mentioned before, you can submit change suggestions on Bugzilla.

Woah, given that this issue was first reported a decade ago in 2011 and then again in 2017 (which was closed as a duplicate of the former) I think it’s safe to assume at this point that nothing will be done about it any time soon and people have just learned to live with it.

Guess I will just add my concern to the pile of comments there. Thanks for your help :slight_smile:

Woah, given that this issue…

Everything can be seen as a issue.
You may be right that many are resigned to it.
But I suppose they also recognize the benefits of restoring a document after a system crash.
So, the world is not all black and white. :wink:

Don’t get me wrong, I appreciate that they’re siding with caution in the absence of refining the feature. But like I said, it’s just got the downside of patterning oneself into ignoring the potentially important document recovery dialogue, because it comes up, every… single… day. No matter what.

I will just have to train myself to close down all my documents manually before shutting down, to avoid this.

1 Like

Could you please give more technical information?

I don’t think the OS, i.e. the kernel, is the culprit. The base cause lies probably in the interface between the desktop manager and LO.

I am under KDE and frequently don’t close my LO windows when ending my session so that I get auto restoration when I login again (which does not happen because LO is not integrated with KDE session management). I had not noticed all the details until I read your question.

  • LO doesn’t block session ending if there are unsaved changes, contrary to many other applications (which get killed after some timeout if no answer is given to the warning dialog)
  • recovery dialog is triggered by the existence of the lock file
    It seems the lock file is created as soon as LO is launched. We could imagine another algorithm where the lock file is created only when a document is loaded and cleared when the last document is closed. A more sophisticated version could be based on not committed changes in opened documents so that force-quitting over fully saved documents does not trigger recovery on restart.
  • LO does not catch termination events forwarded by the desktop manager and therefore cannot react
    For developers defence, there are so many desktop managers and associated events that I understand they didn’t try to implement something. This “something” must be portable between OSes and desktop managers. LO is made to work in any environments, even those without desktop managers (offering only a window manager), so trying to design a universal “something” is probably next to impossible.

Nevertheless, I never blindly ignore the warning. I prefer to answer “Start recovery”, check the result and eventually close without saving to reload.

Yes it’s certainly possible to handle this situation the way other cross platform programs do it, your ideas on how to go about it sound good. But I understand this is a not for profit project, and that the developers must have different priorities, given how much time has passed.

Here’s some system info, let me know if you’d like more.

Operating System: EndeavourOS
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.86.0
Qt Version: 5.15.2
Kernel Version: 5.14.7-arch1-1 (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i7-6700K CPU @ 4.00GHz
Memory: 31.3 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 2060 SUPER/PCIe/SSE2