Description: When the temporary directory (and/or its files) in /tmp are gone for whatever reason, the document can no longer be saved. Libreoffice always complains with error messages, each in its own window. Steps to Reproduce: 1. open and edit some.odt 2. rm -rf /tmp/luPIDrandom1.tmp 3. trying to save changed document will complain with errors Actual Results: +-----------------------------------------------+ | Fehler beim Speichern des Dokuments some.odt: | | Kein Zugriff auf Objekt. | | Aufgrund fehlender Benutzerrechte kann auf | | das Objekt nicht zugegriffen werden. | +-----------------------------------------------+ and +---------------------------------------------------------+ | Fehler beim Speichern des Dokuments some.odt: | | /tmp/luPIDrandom1.tmp/luPIDrandom2.tmp existiert nicht. | +---------------------------------------------------------+ Expected Results: Libreoffice should save the document as it is already in memory. If in doubt, it should offer the save-file dialog to change the filename. Reproducible: Always User Profile Reset: No Additional Info: As workaround, experienced users simply do following (using example as described before): 1. mkdir /tmp/luPIDrandom1.tmp/ 2. touch /tmp/luPIDrandom1.tmp/luPIDrandom2.tmp 3. use save in libreoffice ;-) This also proofs, that there is no reason for libreoffice to bother the user with error messages, because the situation can be handled. Also, the error messages are technically wrong or incomplete which make it hard to get used to the reason. May be this bug is similar to or even the same as described in #160484
Confirm with Version: 25.2.0.1 (X86_64) / LibreOffice Community Build ID: ddb2a7ea3a8857aae619555f1a8743e430e146c9 CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Created attachment 198350 [details] screenshot Screenshot showing the temporar file on the left, that is created after the temporrary files have been removed from that folder, and on the right the error I get.
I have to mentioned that first time, after I removed the temporary file, it was created again by save, and no error. The second try, I get the error.
I brought it up in the developer chat and the consensus was that intentionally breaking the working of the software is not a bug, so I will close.
Hmm, the reported problem *does not* "breaking the working of the software". The "rm" in my example was used to provide a very simple example to reproduce the situation. The mentioned file may disappear for various reasons. Such a situation is not handled by LO appropriate, but bothers the user with wrong and not really understandable error messages beside loosing data. Please see my "Expected Results". IMHO it's a bad habit to blame the user for trapping into software bugs, just because something happend the programmer didn't expect :-( Other suggestion, if you won't fix the bug: Please write a detailled description what these messages mean, how to prevent them and how to solve the problem, probably in the LIMITATIONS|KNOWN ERRORS section. Feel free to decide what's the better approach: documentation or fixing the bug. Please reopen the bug. Please don't get me wrong: it's not about blaming the programmers for not expecting "something". But now there is an example what should be expected. Hope this helps.
BTW, I'm happy to join the chat, if it helps.
Ok, we can repurpose this for better errors.
Thanks. I'm happy to discuss that computers should do what users expect, and not that users do what programmers expect. ;-)
achim: Mike had added bug 159769 to See Also. It affected version 7.4, which is also what you reported this against. Per what you see in its Whiteboard, target:24.8.0 target:24.2.2, can you reproduce your issue with those versions or newer ones?
(In reply to achim from comment #5) While I already added a See Also bug 159769 discussing a "valid" case of clearing temp files on Windows, your bug still needs an explanation, *why* do you consider removal of files created by a software in a temporary storage a normal thing (as if some external actor knows better, what a software may need or not). So - for now, I tent to agree that no, this is not (yet) a bug, but rather invalid assumption that clearing temp files from under a program is OK (and incorrect claim, that others "blame the user for trapping into software bugs").
Cf. that to a fictional claim that "I use a debugger to randomly change memory; your software then misbehaves - it's a bug!". That would be very similar: the temp storage is provided to software for its internal use; it is of course possible to implement hacks to recover even after random (limited) RAM corruption (at the cost of huge RAM and CPU consumption to store/check/use recovery info). Recovering from TEMP storage corruption also has overhead, so needs a very good reason.
Now I had time to test and I don't even reproduce the issue. Arch Linux 64-bit Version: 25.2.4.3 (X86_64) / LibreOffice Community Build ID: 520(Build:3) CPU threads: 8; OS: Linux 6.14; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US 25.2.4-1 Calc: threaded
@Mike Sounds that discussing the potential occourance of an existing problem becomes a stronger effort than thinking about a fix :-( My report was about the error message and loosing data, not about "user removing sofware generated tmpfiles". Please read all comments again, removing the tmpfile (by user) was just to reproduce the problem simply. This problem occours somehow, without interaction of the user (removing tmpfile). However, the user may remove any tmpfile accidently. Temporary - nomen est omen. Again, from a user's perspective, data is lost for whatever reason. @Buovjaga Unfortunately, I can't test with 25.x . So if my "Steps to Reproduce:" no longer produce the error message *and* current data can be saved, the bug may be fixed or gone in 25.x. Feel free to close this one then. Thanks.
(In reply to achim from comment #13) > @Buovjaga > Unfortunately, I can't test with 25.x . > So if my "Steps to Reproduce:" no longer produce the error message *and* > current data can be saved, the bug may be fixed or gone in 25.x. Feel free > to close this one then. If this is about being restricted due to distro packages, you can use an appimage: https://www.libreoffice.org/download/appimage/
(In reply to achim from comment #13) > My report was about the error message and loosing data, not about "user > removing sofware generated tmpfiles". > > Please read all comments again, removing the tmpfile (by user) was just to > reproduce the problem simply. This problem occours somehow, without > interaction of the user (removing tmpfile). Then you have to provide reproduction steps, to prove it is a valid case. Just as I did in bug 159769 comment 3. > However, the user may remove any tmpfile accidently. Temporary - nomen est > omen. This is a user error. Period.
(In reply to Mike Kaganski from comment #15) > Then you have to provide reproduction steps, to prove it is a valid case. > Just as I did in bug 159769 comment 3. Meaning, "steps to see that it may happen in the real life, not using rm"
> Then you have to provide reproduction steps, I did. The real case, when I observed it first, was random. Hence it's nearly impossible to provide exactly these steps for reproduction. We're dealing with a complex world. For me it's boring to discuss the potential occourance of a problem, when we're aware of it. In my world I'll try to avoid or fix it, instead of spending life time searching for someone who is guilty. Unfortunately I can't fix this one, but help to get used to it. Please don't blame the user. The error is always done by the program, because it was told (programmed) to do so. No offence meant. May be it's better we stop the discourse here.
(In reply to achim from comment #17) > > Then you have to provide reproduction steps, > I did. > The real case, when I observed it first, was random. Hence it's nearly > impossible to provide exactly these steps for reproduction. > > We're dealing with a complex world. For me it's boring to discuss the > potential occourance of a problem, when we're aware of it. In my world I'll > try to avoid or fix it, instead of spending life time searching for someone > who is guilty. Unfortunately I can't fix this one, but help to get used to > it. You don't have to fix it as it was already fixed. It is enough to spend some time to figure out how to use a version that is not outdated. > Please don't blame the user. > The error is always done by the program, because it was told (programmed) to > do so. On the other hand, a program is allowed to rely on the resources available to it, CPU, RAM and disk. It seems a bit restrictive to arbitrarily demand that the program should not use a particular resource.
(In reply to achim from comment #17) > > Then you have to provide reproduction steps, > I did. You did not. > The real case, when I observed it first, was random. Hence it's nearly > impossible to provide exactly these steps for reproduction. Then, *if* it's still existent (comment 1 ?), then everyone have to wait for such steps. Without these, we should assume either user error, or another software's error (which requires a bug report to that other software). > We're dealing with a complex world. For me it's boring to discuss the > potential occourance of a problem, when we're aware of it. Fine. But "we" aren't. > In my world I'll > try to avoid or fix it, instead of spending life time searching for someone > who is guilty. "Guilty" is a wrong word. Users are not "guilty" in making errors. Developers are not "guilty" in making errors. But we definitely should not fix other softwares' bugs by adding workarounds in our code, which increases complexity, and is prone to new bugs. > Unfortunately I can't fix this one, but help to get used to it. > Please don't blame the user. Please stop blaming others that they "blame users". > The error is always done by the program, because it was told (programmed) to > do so. Just no. The program indeed does what it was "told" to; but that doesn't make *it* do every "error". A hammer hitting one's toe is not *doing* the error in targeting. > May be it's better we stop the discourse here. No it doesn't. We still need to know (1) if it is fixed (then comment 1 was wrong), and if it is not fixed, then (2) if it *needs* fixing (and for that, my arguments hold true).
> https://www.libreoffice.org/download/appimage/ Thanks for the link, I'll try the AppImage and then come back ... <OT> very first start of LibreOffice-still.standard-x86_64.AppImage exited with status 81, second start worked. </OT> ---- Regarding previous two comments: we agree, that we disagree in some opinions.
ok, tested with AppImage 24.8.7.2 LibreOffice-still.standard-x86_64.AppImage : * save works correct even if tmpfiles are removed * no error occour ---- <OT> Got at least 2 issues (exit with error, no document opened) with Appimage. Should I open bugs for them? </OT>
(In reply to achim from comment #21) > ok, tested with AppImage 24.8.7.2 > LibreOffice-still.standard-x86_64.AppImage : > > * save works correct even if tmpfiles are removed > * no error occour > > ---- > <OT> > Got at least 2 issues (exit with error, no document opened) with Appimage. > Should I open bugs for them? > </OT> The appimage error could be specific to the appimage format itself, not sure. You could also try 25.2. I guess we can close this now.