Apache OpenOffice (AOO) Bugzilla – Issue 116690
OOo eats files when /tmp runs out of space
Last modified: 2011-01-28 16:42:33 UTC
My environment: Ubuntu 10.10 x64, separate / and /home partitions. Scenario: working for two weeks on three documents, saving along the way every few hours. Getting ready to wrap up, I want to verify some wording against the fourth document that I have to open again. Suprisingly, I get "general input/output error". I think oh wtf, it's 4am, lets finish this. I try to save each document one last time, I get "this document is locked; open readonly, open copy, cancel" message. I think wtf again, delete lock files for each, save, quit. Then I want to tar everything up and send my work to client, I notice that all three file sizes are 0. Instead of pulling my hair out I analyzed what happened. It took me a while ... Apparently ubuntu updater installed a new kernel image just hours before I finished my work, filling up all available space on the / partition (hitting the reserved 5% so non-root users could not write to /tmp anymore, but updater running as root figured it still has enough space to do its job). OOo writer then couldn't create new temporary files in /tmp, so opening of fourth document failed with most useless error msg imaginable. I'm not familiar with internals of OOo, but file locking code also seems to fail when /tmp is full. When I deleted lock files, its lock check succeeded, but apparently all files go through /tmp first without checking for any returned erros and are then happily written to their proper place. Therefore all I got was empty files. At no point in the process OOo writer hinted at being short on disk space. This is absolutely unforgivable. All this time /home had over 50GB disk space available. Folks, it's little things like this that make OOo a laughable product when compared to "serious" office suite. Please audit all your code and verify that you properly handle all possible errors returned from file io calls and then make sure that you properly present them to the user so the user can figure out how to solve the problem. Remember, user's data are holy and you must do everything in your power not to lose them. As things stand now, this is not the case.
duplicate *** This issue has been marked as a duplicate of 78897 ***
Closed
I've read through #78897 and I don't agree with the findings there. "Not our problem" is not a proper way to address real world problems. /tmp getting full is a real scenario, despite what those specifications say. And relying on a flawed specs is a bug by itself. It's OOo writer that is loosing user's data, not some spec for some theoretical OS. And as I've said before, user's data are holy and you should do everything in your power to keep them safe. If your code really must go through /tmp to create&check lock files and to save existing documents, there's a temp dir in the profile. What's that for anyway? Also there are issues througout the issue tracker related to out of disk space condition going as far back as I could search. The fact that they still pop up shows there's some ignorance and negligence going on regarding this problem and I find this unacceptable for a product such as Open Office.
I see there's already good reasoning in this direction in #103815. Please raise the priority of this issue, as this is a real world problem.
Yes issue 103815 will help in this /tmp full is a machine maintenance deficit which is indeed not our problem but to some extends a system problem and at first a user problem. *** This issue has been marked as a duplicate of 103815 ***