Sometimes, LO is used to open a file from a website, or a mail message. Such a file is saved temporarily to /tmp (or some similar location depends on your OS); and it is opened in read-only mode, or at the very least - the user hasn't altered it. In this case, it may not make a lot of sense to try and recover this file; or at least not to present its being missing as some sort of failure. I don't have a specific suggestion how to change behavior in this case, but I'm getting these failures almost every time there's a crash, and they're annoying.
Hello Eyal, Thank you for reporting the bug. Unfortunately without clear steps to reproduce it, we cannot track down the origin of the problem. Please provide a clearer set of step-by-step instructions on how to reproduce the problem. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the steps are provided
(In reply to pavlog from comment #1) > Please provide a clearer set of step-by-step instructions on how to > reproduce the problem. I guess I wasn't explicit enough. 1. Ensure LibreOffice is closed 2. Open LibreOffice; ensure no recovery dialog comes up (otherwise handle recovery and return to step 1) 3. Close LibreOffice 4. Open a mail client (say, Thunderbird). 5. View a message with an attachment document you can open with LibreOffice Writer (if you don't have one - send yourself one). 6. Open the file (e.g. by double-clicking it - but this depends on your OS and desktop environment of course); this should launch LO writer with the document 7. Determine where the temporary file LO has opened is located (on Linux and with Thunderbird this might be under /tmp/mozilla_yourname0/the_file ) 8. kill the LO process - aggressively (e.g. with kill -9 if you're on Linux/BSD/Mac; I'm not sure End Process on Windows is enough) 9. Remove the copy of the file from wherever it is located 10. Launch LO. Expected results: No recovery dialog is opened, or a dialog is opened indicating already the special case of a temporary file which is no longer present. Actual Results: A recovery dialog is opened, like for any other document; and the attempted recovery reports a failure.
(In reply to Eyal Rozenberg from comment #2) Thanks for providing the steps. What LO version do you use? I can't reproduce it in Version: 7.0.3.1 (x64) Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
(In reply to pavlog from comment #3) > I can't reproduce it in 7.0.3.1 I kind of doubt that's possible... What happens on your system after step 10? > What LO version do you use? About the same: Version: 7.0.3.1 Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 4; OS: Linux 5.2; UI render: default; VCL: gtk3 Locale: he-IL (en_IL); UI: en-US Calc: threaded
(In reply to Eyal Rozenberg from comment #4) > > I kind of doubt that's possible... What happens on your system after step 10? > No recovery dialog is opened, as stated in Expected results
(In reply to pavlog from comment #5) > No recovery dialog is opened, as stated in Expected results At this point I would need the expertise of someone to know the source code, to tell us whether LO actually has logic for this situation, or whether it's "reproduction trouble". In the mean time - can you tell me how you killed LibreOffice on your system? Maybe that has something to do with it?
(In reply to Eyal Rozenberg from comment #6) > (In reply to pavlog from comment #5) > In the mean time - can you tell me how you killed LibreOffice on your > system? Maybe that has something to do with it? I did it as usual by Ctrl+Alt+Del - TaskManager - Processes - End task
I reproduce on Linux, so let's treat this as Linux-only so far. Arch Linux 64-bit Version: 7.0.3.1 Build ID: 00(Build:1) CPU threads: 8; OS: Linux 5.9; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US 7.0.3-2 Calc: threaded
Dear Eyal Rozenberg, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Seeing this with : Version: 7.4.2.3 / LibreOffice Community Build ID: 40(Build:3) CPU threads: 4; OS: Linux 6.0; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US Debian package version: 1:7.4.2-4 Note that, on Linux you can figure out which file is being used by opening a command-line and running `ps aux | grep soffice`. I found my Writer using /tmp/pid-NNNN/the_file_name as the filename, where NNNN is some number. This may depend on your choice of distribution though or the LO version.
*** This bug has been marked as a duplicate of bug 57414 ***
(In reply to Stéphane Guillou (stragu) from comment #11) Bug 57414 is about read-only files; this is about temporary files. While the two bugs are related, this is not a dupe. If you want to expand the scope of 57414 to also cover temporary files, then I would be ok with resolving this one as a dupe.
(In reply to Stéphane Guillou (stragu) from comment #11) > *** This bug has been marked as a duplicate of bug 57414 *** It probably should remain a duplicate, but oh well. I disagree that just because it is in the /tmp directory it shouldn't be in the recovery system - but I can agree that if it is unmodified it doesn't need to be. For example, if someone e-mails me a file, and I open it and then start making changes to it for an hour, what should happen if LO crashes? I would want to be able to have it recovery my hour's worth of changes when LO restarts - even though I hadn't properly saved it to a reasonable location yet.