Description: libreoffice complains at startup with the error message "Write Error. The file could not be written.". libreoffice then exits without error message or status. Sometimes it happens when libreoffice is running, a second headless instance was executed like: "libreoffice -env:UserInstallation=file:///tmp/tst --cat some.tld" and then a new document is opened. To get rid of the error, all instances of libreoffice must be closed, but then you may run into the problem described in #164332 , means that changes can get lost. Steps to Reproduce: 1. env TMP=/michgibtsbestimmtnicht libreoffice some.tld Actual Results: libreoffice exists Expected Results: Should work flawless ;-) At least an information should be shown how to proceed. Reproducible: Sometimes User Profile Reset: No Additional Info: The "Steps to Reproduce" are a very simple example, hopefully pointing to the same reason and behaviour as described in "Description". Additionally I've observerd that sometimes ~/.config/libreoffice/4/.lock was removed after calling "libreoffice -env:UserInstallation=file:///tmp/tst ..." (but can't reproduce it reliably). May be this bug is related to #160484 #164332 #164340
Bug 63554 seems relevant. You can solve this by having multiple parallel installations with separate user profiles, see: https://wiki.documentfoundation.org/Installing_in_parallel
Just to clatify, my initial report has nothing to do with multiple users, it happens if several LO processes are tunning for the same user (which is the common case in unixoide systems;-)
(In reply to achim from comment #2) > Just to clatify, my initial report has nothing to do with multiple users, it > happens if several LO processes are tunning for the same user (which is the > common case in unixoide systems;-) And were these separate installations? In your comment "libreoffice" sounds like the same installation, as opposed to "path/to/soffice" + "a_different_path/to_a_different/soffice".
My test case used the same office.bin for all processes. If you mean my path "~/.config/libreoffice/4/", that was just a real example, has nothing to do with multiple versions of LO. I've to admit, that I don't know anything about the implementation. For me it seems to be related to the headless mode (probably some others also), somehow. It's a second process for the same user. Didn't check if LO handles this as a new process or instructs a running process to create a new thread. At least multiple LO where running. Anyway, when using tempfile() from libc, it should generate a new filename for each call.
same behaviour as described with AppImage 24.8.7.2, tested with: env TMP=/michgibtsbestimmtnicht LibreOffice-still.standard-x86_64.AppImage some.odt