Issue 116690 - OOo eats files when /tmp runs out of space
Summary: OOo eats files when /tmp runs out of space
Status: CLOSED DUPLICATE of issue 103815
Alias: None
Product: Writer
Classification: Application
Component: save-export (show other issues)
Version: OOo 3.2.1
Hardware: PC (x86_64) Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: writerneedsconfirm
QA Contact: issues@sw
Depends on:
Reported: 2011-01-28 14:13 UTC by Unknown
Modified: 2011-01-28 16:42 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description Unknown 2011-01-28 14:13:53 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 

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.
Comment 1 eric.savary 2011-01-28 14:21:05 UTC

*** This issue has been marked as a duplicate of 78897 ***
Comment 2 eric.savary 2011-01-28 14:21:22 UTC
Comment 3 Unknown 2011-01-28 16:23:37 UTC
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.
Comment 4 Unknown 2011-01-28 16:33:50 UTC
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.
Comment 5 eric.savary 2011-01-28 16:42:16 UTC
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 ***
Comment 6 eric.savary 2011-01-28 16:42:33 UTC