At the moment LibreOffice what happens when LibreOffice was closed without all documents saved is something which was seemingly build for a crash recovery. I use Linux (KDE) which has the benefit of a session management. It restores all the documents which were open when the system was shut down (regulary). I wish that LibreOffice would handle this specific case better: - If I am using session management, I do not want to answer any questions, which documents should be restored. It should just happen. - It does not make sense to try and restore documents which were stored in the /tmp-folder since this will be deleted on reboot. So I do not need any message which tell me that restauration failed on those.
Even for people without session management, the document recovery for files in /tmp is a real pain. I often use libreoffice to open attachements to my emails. My mailer makes a copy in /tmp and after that, libreoffice keeps complaining about document recovery failures on startup, for a file that was deleted long ago. I couldn't find a better way than "rm -fr ~/.libreoffice" to get rid of the document recovery failure message in this case.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Additionally Libreoffice should (optionally is best, I guess) not block the shutdown of the system and instead just store the session. Or it shut just block the session for a limited time asking the user I he wishes to save, meanwhile store the session anyway and if there is no reaction let the shutdown go its way without permanently blocking it.
Bump, because this is still a problem with KDE. Example of good behaviour: kwrite interrupts (and potentially cancels) the shutdown/logout if files need saving. It reloads saved files on session load.
Not 100% sure but I think I'm referring to this bug with a slightly different use case too. Steps to reproduce: (On Windows 7 SP1 (64-bit) - tested with LibreOffice 5.0.5 (64-bit)): 1. Create a new document (for instance a LibreOffice calc document). 2. Make some changes and save the file. 3. Without closing LibreOffice shutdown Windows. 4. Bootup Windows again. 5. Open the document you just created. Actual result: Libre Office brings up the Document recovery dialog. Expected result: Document is opened without bringing up the document recovery dialog (since everything was saved correctly). From a users point of view it therefore looks as if the recovery function in libre office doesn't check whether anything in the recovery file wasn't saved in the real document and/or the recovery file isn't deleted, when LibreOffice is closed due to a Windows shutdown.
*** Bug 113579 has been marked as a duplicate of this bug. ***
LibreOffice is the only program I have which I need to manually close before shutting down. All other programs that have file recovery dialogues will respect a shutdown and close gracefully, only bringing up the file recovery dialogue when the program was actually terminated prematurely (eg. you can trigger it by force quitting the program). When LibreOffice receives a shutdown request from the system, it simply has to gracefully close all open documents the same way the user would manually, and only stop if there is anything unsaved, at which point, if shut down continues, we can leave the lock file there and the recovery dialogue will be triggered next time.
That's not really an enhancement. It should be considered as bug: - Create a document. - Save it on disk: test01.odt - While LibreOffice is still open, close the session and reboot. - Open another document, which you have yet on disk, with LibreOffice: olddocument.odt Actual result: Instead of opening immediately olddocument.odt, LibreOffice asks you if you want to restore test01.odt. That is something unrelated to the action you are performing. Expected result: olddocument.odt is opened immediately, without any questions about restoring. If LibreOffice gained support for full session management, that would be a (well appreciated) enhancement. However, I think it is clearly a bug to open “document restore” dialog for test01.odt which was saved before and did not lose any information. Furthermore, the “document restore” dialog suggests that there is information lost, because usually that's what comes after a crash where you indeed lost information. So this dialog leaves makes the user fear that he lost information previously without even noticing it.
(In reply to sommerluk from comment #8) This is requesting the exact opposite reaction to what OP is requesting. And I fully disagree with the premise. If LO is closed by OS-shutdown, any session documents should be recovered on startup. I also disagree with OP who wants everything restored without even a simple dialog requesting confirmation. That is SUPER SIMPLE to answer (at least now in 2023) and a very rational response (as indicated by comment 8 who does not want to recover these). WONTFIX as far as I am concerned.
I learned a bit more about AutoRecovery today. (In reply to Mark from comment #0) > At the moment LibreOffice what happens when LibreOffice was closed without > all documents saved is something which was seemingly build for a crash There are three types of AutoRecovery. Timed autorecovery is for hard crashes, and EmergencySave is for soft crashes. The OS sending a kill signal would trigger one of these two, which you are probably experiencing. The third type is a SessionSave, and it does restore all documents silently. It even silently ignores /tmp files etc. > I use Linux (KDE) which has the benefit of a session management. Based on my commit reading, it sounds like work was done to support KDE session management. However, in my testing I didn't get it to work. However, all the pieces are there - they just need to be wired up properly. vcl/unx/generic/app/sm.cxx vcl/source/app/session.cxx > I wish that LibreOffice would handle this specific case better: A valid desire. Needed for KDE, GTK, Windows (bug 109085). > - If I am using session management, I do not want to answer any questions, > which documents should be restored. It should just happen. If officecfg::Office::Recovery::RecoveryInfo::SessionData is true instead of officecfg::Office::Recovery::RecoveryInfo::Crashed, it will be silent. > - It does not make sense to try and restore documents which were stored in > the /tmp-folder since this will be deleted on reboot. Or SessionSave could ensure there is a recoveryFile available for them. This would certainly be useful for USB or disconnected server files.
For GTK - it looks like VCLSession needs to be wired into the changes made for bug 142176.
*** Bug 157709 has been marked as a duplicate of this bug. ***
(In reply to Justin L from comment #11) > looks like VCLSession needs to be wired into the changes made for bug 142176 Yup, I still think so. In GTK (Cinnamon), it looks to me like every document receives the session_client_signal, so all the frames would need to coordinate a single call to vnd.sun.star.autorecovery:/doSessionSave and vnd.sun.star.autorecovery:/doSessionQuietQuit. And that is what VCLSession appears to be in charge of.