After a crash, document recovery fails Error Message: "<FILENAME> does not exist." Followed by "Object not accessible. The object cannot be accessed due to insufficient user rights" THe interface then prompts me to save to a directory, but it does not save anything there when you go through the process with the filesave window. It then opens the last saved version of the file from its original place on the disk, which is confusing, since the prompts lead me to think it will be the doc that was not saved to the other directory in the previous dialogs. Same problem as #95534, except this is version 5, not 4, and I am not the rude guy who reported the other bug :) LMK if you need more information.
oops, that should be "same problem as in *93137* except that...", not 95534, which is my report for the bug that caused the crash that file recovery fails for.
Hi Rich, Thanks - set this to new. Since I have this _now and then_ too. Now need a reliable approach to reproduce.. Can you give that? Why do you refer to bug 93137 and what is different? thanks, Cor
(In reply to Cor Nouws from comment #2) > Now need a reliable approach to reproduce.. > Can you give that? It seems random but quite regular for me (due to power outage). > Why do you refer to bug 93137 and what is different? He's saying it's the same, and I agree. I want to mark this is duplicate of that, but I'm reluctant to make that report the main one for reference due to the reporter's rudeness. At any rate, it's annoying. Can I mark this as major?
Has anyone tried kill -9? I mean, fair enough, I have not; but these reports suggest that the problem is independent of the type of crash, itself. I think we are giving reasonable reproduction scripts: any crash will case the problem. It also happened again, for me, after a sudden power reset (but I have LO4). That's what happened to OP, too, however. So, now we have a confirmed reliable approach: power cycle your computer with multiple documents open. (Multiple documents helps because you can see the series of errors for each document that was open.)
I have been getting recovery failures repeatedly including when I have been relying on libreoffices ability to recover after having a computer hang that causes need of a reboot. The backup file in ~/.config/libreoffice/4/user/backup/ indeed does not exist. I would think that it would be created as soon as one makes some changes to a document without saving, but this definitely is not happening.
*** Bug 93137 has been marked as a duplicate of this bug. ***
Changing "Hardware" to All as it affects Windows and Linux versions. Since it may involve data loss, can we mark this as major?
has anybody retested it with latest LibO 5.0.3.2 release?
I have done a couple of tests to find when the backup file is created. It is not created immediately after a document is opened nor immediately after it is edited, there appears to be a timeout which has to elapse after one or both of these events before the backup file is created. Not sure the length of the timeout. Recently (a few weeks ago) I turned power saving on with a small timeout of 15 minutes which means that the PC may go into power saving mode after a document is opened but before the backup file is created and sometimes the system wont wake from power saving mode and a reboot is required. This power saving lock up is a separate bug but it causes libreoffice to attempt recovery of the files that were open before the reboot but the message about missing backup files is correct as they were in fact not created. Before I turned power saving on lock ups requiring reboot were rare and I only occasionally experienced the libreoffice recovery fail problem, after that they became a nagging recurrence and multiple times I lost edits that I relying on recovery to protect. Today I reset the power saving timeout to 90 minutes if I am correct in my hypothesis I should experience less of this problem.
(In reply to Carlyle Moulton from comment #9) > I have done a couple of tests to find when the backup file is created. It is > not created immediately after a document is opened nor immediately after it > is edited, there appears to be a timeout which has to elapse after one or > both of these events before the backup file is created. Not sure the length > of the timeout. That's to be expected. It gets created based on what you specify at Tools - Options - Load/Save - General - Save AutoRecovery information every (Default: 15 minutes) (I set mine to 2.)
My previous comment #9 is wrong. Since I made it I have done another test with a 3rd document XLOG07 which I opened on 2015-11-5 before 21:04 and edited multiple times at:- 21:06 21:35 22:20 22:45 23:52 While periodically checking the contents of ~/.config/libreoffice/4/user/backup to see whether the backup file had been created. As at 13:01 on 2015-11-6 the backup file is still nonexistent. The problem is that sometimes libreoffice fails to create a backup file when it should do so, any subsequent computer hang requiring a reboot exposes the fact that the file does not exist, the document recovery failure message is correct. My version of libreoffice is 4.4.5.2 Build ID: 4.4.5.2-8.fc22 Locale: en_AU.UTF-8 my Linux is Fedora 22 X64.
In reply to Kumara at Comment #10. My update time out is set to 15 minutes, always create a backup copy is not checked. I will check it and see if that makes any difference.
After the changes in comment 12, changing save recovery timeout to 2 minutes and checking always create backup copy a XLOG07.bak file appears in the libreoffice backup directory, note the .bak file is not the file specified in the error message which is an .odt_O.odt file.
Always Create Backup Copy specifies creation of the .bak file Automatically save the document too specifies creation of the .odt_O.odt file. I have now checked both of these and set the timout to Kumara's suggested value of 2 minutes. Will cross fingers and observe.
(In reply to Carlyle Moulton from comment #14) > Always Create Backup Copy specifies creation of the .bak file > Automatically save the document too specifies creation of the .odt_O.odt > file. You can ignore the .bak file. It's not relevant to this.
These symptoms are a match for me. However, I've been running with autosave set to 2 minutes for a long time, certainly before this problem began, which was a long time ago. So, I don't think the problem is improved by reducing the autosave time delay. Libreoffice correctly detects when it was interrupted and that recovery is required. It's just not able to recover correctly.
(In reply to PMouse from comment #16) > These symptoms are a match for me. However, I've been running with autosave > set to 2 minutes for a long time, certainly before this problem began, which > was a long time ago. > > So, I don't think the problem is improved by reducing the autosave time > delay. Libreoffice correctly detects when it was interrupted and that > recovery is required. It's just not able to recover correctly. I wonder if I've misunderstood Carlyle, or you have. As I understand, he just needed to make the time shorter so that he can monitor how the Autosave function is mulfunctioning so that it causes the recovery failure. Anyway, I've upgraded to LO5, and it seems the problem is no longer there. Not sure how it got fixed, but question now is whether the coders want to backport the fix.
Thank You Kumara for your comment #14. I have set check boxes:- Always Save the Document Too & Always Create Backup Copy and have been running with these settings since my last comment #15 on 2015-11-06 06:36:10 UTC, and my instances of the missing .odt_1.odt file have been much reduced and those that have occurred related to cases where there was no need to recover the specified document anyway:- 1/ Document has been opened but not modified and therefore the file copy is up to date; 2/ Document has been opened, edited and then saved under another name so again the file of the original name is up to date. I am puzzled as to where .bak files fit in to the picture, these hang around forever and are not deleted when no longer needed. I have had one other instance of the missing .odt_1.odt about which I am not sure, it may have been an instance of case 1/ above but I am not sure I did not accidentally bump a key when browsing it.
(In reply to Carlyle Moulton from comment #18) > I am puzzled as to where .bak files fit in to the picture, these hang around > forever and are not deleted when no longer needed. As I said, it is irrelevant here. (It's only relevant when you do manual save.)
Here's some info that might help to get a clearer picture of the bug. Background info: I save my work in versions. Not using LO's version feature, but simply saving in a new file, and store up the old file. The bug I notice: When I have done "Save as..." a new file, say "ABC 7.5.odt", and later have LO terminate suddenly (power outage in my case), upon reloading LO, the recovery routine will try to recover an autosave version of "ABC 7.4.odt", which doesn't exist either. (Actually, it would try to look for "ABC 7.4.odt_0.odt".) I also notice that the recovery routine tries to look for the file in the "backup" folder. Now, while I can't trust my memory to be perfect, I recall that it should be elsewhere: the temporary files folder. It seems somehow the recovery system is mixing up the 2 folders, and this may be the cause of the problem. I'm changing the "earliest affect version" to 4.4.1.2 as indicated in the duplicate report.
Adding "regression" to Whiteboard. Because of this bug, LO recovered an earlier version of my work (more than 100 pages). Not knowing that, I worked on that version, and found out later to my consternation! Request to have the importance changed to major, because this can cause data loss.
Migrating Whiteboard tags to Keywords: (regression) [NinjaEdit]
(In reply to Rich R from comment #0) > After a crash, document recovery fails > > Error Message: > > "<FILENAME> does not exist." > > Followed by > > "Object not accessible. > The object cannot be accessed > due to insufficient user rights" > > THe interface then prompts me to save to a directory, but it does not save > anything there when you go through the process with the filesave window. It > then opens the last saved version of the file from its original place on the > disk, which is confusing, since the prompts lead me to think it will be the > doc that was not saved to the other directory in the previous dialogs. Same > problem as #95534, except this is version 5, not 4, and I am not the rude > guy who reported the other bug :) > > LMK if you need more information. still getting this bug in Version: 5.0.3.2 Build ID: 5.0.3.2 Arch Linux build-2 Locale: en-US (en_US.UTF-8) also started with a fresh profile.
update: had a system freeze from an unrelated problem that caused a reboot while three libreoffice docs were loaded. THey had all been loaded for several days without interruption, so the timer for autosave was not an issue. Two were recovered successfully upon reboot. the third was not, and caused the loss of a fair amount of work. My own fault: I had never bothered to save the file, since it was an intermediate, scratchpad version of what I am dong. nonetheless, the data was lost, a few hours of writing. And if backup/recovery worked the way the dialogs say, then I would not have lost it. system data: Version: 5.0.5.2 Build ID: 5.0.5.2 Arch Linux build-1 Locale: en-US (en_US.UTF-8) Process: 3 docs open for several days. two had been saved before, one, "untitled 1" had not. system freeze==>reboot with power switch==>restart libreoffice Upon restart of libreoffice: 1. present recovery window: status says it shows whether doc can be recovered, but the actual information is "not recovered yet" which does not give what the message promised. Supposed to get info on whether it is possible. Instead info is on whether it has been done. press start recovery. result: error: /home/xxxx/.config/libreoffice/4/user/backup/untitled_0.odt does not exist. click through. Followed by Object not accessible. The object cannot be accessed due to insufficient user rights. no mention of what or where the object is. click through. "Recovery of your docs was finished. click finish to see docs." two previously saved documents recovered successfully. THe one in question, "untitled 1" shows: "status: recovery failed" click on finish instead of finishing (i.e., opening the two files it did recover) , it gives a new dialog: "automatic recovery process has been interrupted" (It was not. previous window had said it was completed). "THe docs listed will be saved in the folder noted below if you click save." folder was defaulted to "/home/xxxx. changed to /home/xxx/tmp, which I have set to 777 in case it was a permissions problem ( I really wanted the doc back!). document listed as "untitled 1" clicked save. dialog dimissed. The other two successfully recovered docs open. "untitled 1" does not, nothing gets saved in /home/xxxx/tmp. Checking settings in libreoffice: backup folder is supposed to be /home/xxxx/.config/libreoffice/4/user/backup, but noting is there either. nor in /tmp, which is the setting for temp files in libreoffice paths. data lost. expected result: data recovered at any of the appropriate dialogs above. workaround: "did you back it up? LOL." i.e., don't keep docs unsaved , because they will not be recovered.
(In reply to Kumāra from comment #17) > Anyway, I've upgraded to LO5, and it seems the problem is no longer there. > Not sure how it got fixed, but question now is whether the coders want to > backport the fix. Actually, the problem remains. Since this involves data loss, should we set it to major?
Looks like another duplicate of issue 96607. Same time the issue was initially reported (end of 2015), same problem. The initial description of issue 96607 imho perfectly describes the root cause of the problem with document recovery without going through a long discussion fist. Also that issue has severity high (which I believe is appropriate in the case of data loss). So I suggest you add your issue as a duplicate too.
Fully agree with Matthias Basler (though that title sound less critical). *** This bug has been marked as a duplicate of bug 96607 ***