[Bug 160769] LibreOffice 24.2 Document recovery (from timed autoSave) doesn't restore all open files after crash
https://bugs.documentfoundation.org/show_bug.cgi?id=160769 Justin L changed: What|Removed |Added Assignee|libreoffice-b...@lists.free |jl...@mail.com |desktop.org | Keywords||bibisected, bisected, ||regression Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #14 from Justin L --- (In reply to BikeHelmet from comment #6) > That suggests that there is a bug here? If emergencySave is supposed to > recover everything, and after a crash it doesn't, then clearly it crashed in > such a way that it did not have a chance to do so, and is depending upon the > timed autoRecovery instead? Sure, that could be considered a bug. However, that is a huge, expert topic, so I can't imagine anyone looking at it unless a company wants to pay tens of thousands for that investigation. Hmm - I see I didn't read comment 2 closely enough, which clearly stated that "recent documents" was not adequate for that use case. I decided to just revert my change and reopen bug 57414. Bug 146769 and its duplicates are probably another good indicator that a large user segment may not appreciate a clean RecoveryList. So best to just keep the status quo instead of insisting on a controversial change. Backport to 24.2 is in progress... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 160769] LibreOffice 24.2 Document recovery (from timed autoSave) doesn't restore all open files after crash
https://bugs.documentfoundation.org/show_bug.cgi?id=160769 --- Comment #13 from Commit Notification --- Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/852cd511258e97a0df3b6fbe9fc0ae670c3fc843 tdf#57414 tdf#160769 autorecovery: keep open docs in RecoveryList It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 160769] LibreOffice 24.2 Document recovery (from timed autoSave) doesn't restore all open files after crash
https://bugs.documentfoundation.org/show_bug.cgi?id=160769 Commit Notification changed: What|Removed |Added Whiteboard||target:24.8.0 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 160769] LibreOffice 24.2 Document recovery (from timed autoSave) doesn't restore all open files after crash
https://bugs.documentfoundation.org/show_bug.cgi?id=160769 Mike Butash changed: What|Removed |Added CC||mich...@butash.net --- Comment #12 from Mike Butash --- Has there been any decision or update on this? Combine with 160864 with saves broken in kde plasma6 and pipewire periodically causing a hard crash now, it's making libreoffice painful enough to use that I'm having to switch to actually using gsuite for things lately after 20 years. Plus starting without kf6 breaks/changes settings, loses/forgets my backup restoration files in doing so, other ugliness of the default theme when I forget to restart specifically defining SAL_USE_VCLPLUGIN=gen vs kf6. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 160769] LibreOffice 24.2 Document recovery (from timed autoSave) doesn't restore all open files after crash
https://bugs.documentfoundation.org/show_bug.cgi?id=160769 --- Comment #11 from bikehel...@gmail.com --- (In reply to Stéphane Guillou (stragu) from comment #10) > I think solutions like bug 146769 and bug 117237 should be prioritised, > instead of some users relying on killing the process to restore all > documents. > > But considering some users are surprised by the new behaviour, I'm wondering > if the dialog could somehow show all files, but differentiate between > modified and unmodified ones, like two sections with "Needs recovering" and > "Changes already saved" headers, still giving the options to restore > unmodified. That would make it clear what might have missing data, and what > definitely wouldn't. > Just a thought. There's no need to reinvent the wheel here. Standard behaviour in Windows is to stick a * in front of the filename if it needs saving. Although not universal, I have seen that in Linux Distros and MacOS as well. You can use the same dialog window, with all files present, and just stick a * on the ones with unsaved changes. If the list is sorted alphabetically, that should also put them straight at the top. Then put two buttons below: [Recover All Documents] [Recover Only Unsaved Documents] to determine the recovery behaviour that the user gets. And then put in a new confirmation when exiting LibreOffice from the File menu specifically (not the X in the top right), similar to the Opera Web Browser. "Reopen all documents at next start?" [Yes] [No] [Cancel] (Not the wording of Opera's, but you get the idea once you've tried it once or twice.) And then as a final quality of life update (This would require larger code changes), have it backup the open documents (on exiting) to the working drive so that even if the originals disappear, it can fully recover everything at the next start - both modified and unmodified - if desired. This should be toggleable in the Settings in the Load/Save area. Likely beside the "Always create a backup copy" option, which saves backups onto the working drive when saving. I would split that to two options if implemented, "Always create a backup copy when saving", and "Always create a backup when exiting LibreOffice" If this is implemented, it should alert you if the original for reopened documents is no longer present. The type of person using this feature regularly would want to know if suddenly their original has been renamed/deleted/etc from outside of the program. So this adds a lot of polish on top, for that type of user, in that you are treating their precious documents as extra important. By slightly modifying the recovery feature you effectively add a full secondary backup layer to LibreOffice - unless they shut it off. At least a few people would heap praise on the programmers if implemented right. The wording that I would use (on a bright banner bar at the top of the open document) would be: "This document was not found at the previous filename and location. Please re-save this or reopen the original if necessary." That alerts the user to go re-open it if it changed from (for example) "2024-03 Quarterly Inventory.ods" to "2024 Q1 Quarterly Inventory.ods", etc.; they either go open the proper one and save to it, or re-save the open one and continue on from there. It avoids them accidentally splitting their document into two chains when they (or someone else) were doing folder/filename cleanup. That's about all the gotchas that I can think of. With that implemented, it becomes an incredibly handy feature for one type of user. Even with only a limited / first part implementation, it's much more useful than what we have now. I hope that helps a programmer that doesn't need this at all, to understand a feature implementation that would be very useful to some other types of users. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 160769] LibreOffice 24.2 Document recovery (from timed autoSave) doesn't restore all open files after crash
https://bugs.documentfoundation.org/show_bug.cgi?id=160769 --- Comment #10 from Stéphane Guillou (stragu) --- I think solutions like bug 146769 and bug 117237 should be prioritised, instead of some users relying on killing the process to restore all documents. But considering some users are surprised by the new behaviour, I'm wondering if the dialog could somehow show all files, but differentiate between modified and unmodified ones, like two sections with "Needs recovering" and "Changes already saved" headers, still giving the options to restore unmodified. That would make it clear what might have missing data, and what definitely wouldn't. Just a thought. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 160769] LibreOffice 24.2 Document recovery (from timed autoSave) doesn't restore all open files after crash
https://bugs.documentfoundation.org/show_bug.cgi?id=160769 --- Comment #9 from Mike Butash --- Yes, I agree with others, I too have long used/expected (and welcomed) the behavior of it opening not only files with unsaved changes, but also files I work on perpetually or at least extended periods for customer engagements. I as well was ready to file a bug (sort of did, but for other kde framework problems), but was steered here as a separate thing. I can see both sides of the coin, but this "fix" was certainly unexpected and unwelcome behavior for me as a bug/not bug. If nothing else, I would ask for an option to restore only unsaved files, or restore all open files. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 160769] LibreOffice 24.2 Document recovery (from timed autoSave) doesn't restore all open files after crash
https://bugs.documentfoundation.org/show_bug.cgi?id=160769 BogdanB changed: What|Removed |Added Blocks||77999, 112970 CC||buzea.bog...@libreoffice.or ||g Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=77999 [Bug 77999] [META] Autosave/Autorecovery/Backup copy issues https://bugs.documentfoundation.org/show_bug.cgi?id=112970 [Bug 112970] [META] Document recovery bugs and enhancements -- You are receiving this mail because: You are the assignee for the bug.
[Bug 160769] LibreOffice 24.2 Document recovery (from timed autoSave) doesn't restore all open files after crash
https://bugs.documentfoundation.org/show_bug.cgi?id=160769 --- Comment #8 from Justin L --- (In reply to snail from comment #7) > rather a function which should be implemented directly That is bug 146769 (Reopen documents from previous session on start). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 160769] LibreOffice 24.2 Document recovery (from timed autoSave) doesn't restore all open files after crash
https://bugs.documentfoundation.org/show_bug.cgi?id=160769 --- Comment #7 from snail --- I also thought this was a kind of regression and was going to file it as a bug. Before updating to 24.2, I have often left several files opened which need constant attention whether they are worked on or not, and killed soffice.bin process manually in order to restore the status later in the same way as the Internet browser restores previously opened tabs. Still, when it comes to AutoRecovery on Libreoffice, I know it is not an expected behavior, so I understand that this is not a bug, rather a function which should be implemented directly or via an extension. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 160769] LibreOffice 24.2 Document recovery (from timed autoSave) doesn't restore all open files after crash
https://bugs.documentfoundation.org/show_bug.cgi?id=160769 bikehel...@gmail.com changed: What|Removed |Added Resolution|NOTABUG |--- Ever confirmed|0 |1 Status|RESOLVED|REOPENED --- Comment #6 from bikehel...@gmail.com --- (In reply to Justin L from comment #4) > Quoting from bug 57414 comment 22: > > There are three types of Recovery. One is emergencySave (an exception in the > program triggers a save-and-restart), another is SessionSave (when the OS > shuts down), and the third is a timed autoRecovery. > > In the case of EmergencySave and SessionSave, the intent is to recover the > working environment, so ALL documents are attempted to be recovered. > > In the most general case (the timed autoRecovery) the patches only try to > recover modified documents that have a recovery file. > > > So, I tend to agree with Mike in comment 1 and the request to specifically > do it this way in bug 148438. In response to OP, I'd say that recent > documents exists to find those documents easily, so I don't see how > re-opening documents manually could be a problem. > > In general, it is not a good idea to have lots of documents open, so having > LO "recover" the entire last environment would not be smart and encourage > bad behaviour. In this case LO itself has no idea why it is restarting, so > it is best to just recover modified-but-not-saved files. That suggests that there is a bug here? If emergencySave is supposed to recover everything, and after a crash it doesn't, then clearly it crashed in such a way that it did not have a chance to do so, and is depending upon the timed autoRecovery instead? So there's a bug, just not the one from the original post. It still seems like it would be more prudent to give people the choice. An overlapping layer of reliability. The recent documents list is often not long enough, and organizes based on time originally opened, not which documents were recently used. If your work involves opening and closing a bunch of incoming documents or supplier sheets throughout the day, but not working with them, and instead working within other documents that are left opened longer - then it will not have useful files in the list. At the end of the day it's your choice as the developers/maintainers, but I would encourage you to think of users that are in the business world and not in the programming or home use world. It may be bad behaviour, but it's exactly how many businesses work, like restaurants. Another option if this is very unappealing, would be to create a "recently saved" list - as this type of user has no use for recently opened documents, and only cares about the ones that they are saving. The priority is completely opposite to how Justin outlined. Work sheets and supplier pricing updates and whatnot can just be redownloaded/reopened from email, but the documents opened for a long time are actually the priority. Those ones are the ones that are sometimes ignored by auto recovery and the recents list, depending on saving behaviour and how long ago they were originally open. Just food for thought, but I think they could be good changes to broaden the appeal to different types of users and use cases. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 160769] LibreOffice 24.2 Document recovery (from timed autoSave) doesn't restore all open files after crash
https://bugs.documentfoundation.org/show_bug.cgi?id=160769 Stéphane Guillou (stragu) changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTABUG --- Comment #5 from Stéphane Guillou (stragu) --- Thanks Justin. Let's close as "Not a bug" then. BikeHelmet, if you think a different path can be taken to avoid confusion (maybe better text in the dialog?), please feel free to open an enhancement request. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 160769] LibreOffice 24.2 Document recovery (from timed autoSave) doesn't restore all open files after crash
https://bugs.documentfoundation.org/show_bug.cgi?id=160769 Justin L changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=14 ||8438 Summary|LibreOffice 24.2.1 Document |LibreOffice 24.2 Document |recovery only restores 1|recovery (from timed |document after crash|autoSave) doesn't restore ||all open files after crash --- Comment #4 from Justin L --- Quoting from bug 57414 comment 22: There are three types of Recovery. One is emergencySave (an exception in the program triggers a save-and-restart), another is SessionSave (when the OS shuts down), and the third is a timed autoRecovery. In the case of EmergencySave and SessionSave, the intent is to recover the working environment, so ALL documents are attempted to be recovered. In the most general case (the timed autoRecovery) the patches only try to recover modified documents that have a recovery file. So, I tend to agree with Mike in comment 1 and the request to specifically do it this way in bug 148438. In response to OP, I'd say that recent documents exists to find those documents easily, so I don't see how re-opening documents manually could be a problem. In general, it is not a good idea to have lots of documents open, so having LO "recover" the entire last environment would not be smart and encourage bad behaviour. In this case LO itself has no idea why it is restarting, so it is best to just recover modified-but-not-saved files. -- You are receiving this mail because: You are the assignee for the bug.
