Issue 103815 - OpenOffice shows inappropriate error message displayed in objects when tempfile(s) could not be read or written
Summary: OpenOffice shows inappropriate error message displayed in objects when tempfi...
Status: CONFIRMED
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: OOO310m11
Hardware: All All
: P3 Trivial with 1 vote (vote)
Target Milestone: AOO Later
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
: 116690 (view as issue list)
Depends on:
Blocks:
 
Reported: 2009-07-26 13:57 UTC by k4os
Modified: 2013-02-07 22:36 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description k4os 2009-07-26 13:57:54 UTC
When a tempfile corresponding to an object cannot be created (p.ex. because
there is no more space in $tempdir) the frames of the object states "read
error". This is correct in the way, that the tempfile could not be read, however
there a two drawbacks:
- the user is not told that it is the tempfile that could not be read. Most
users assume (I'm producing a quite big document with a group of schoolmates)
that the file they tried to open is corrupted. OOo should tell the user that its
only the tempfile.
- OOo should tell the user when the initial problem occurs, what the problem is
and if that is possible, how he can solve it. There is another issue (#95243)
that deals with the same problem (impossibility to create tempfiles is not
communicated), but the user got the problem under different circumstances
(saving the document)

to reproduce this: either open a document larger than current available
tempspace, or reduce available tempspace before attempt to open a usual sized
document with pictures in it.

<postamble>So this issue is another one corresponding to the problem "No
tempspace available", there are multiple bug reports that directly adress the
problem (#78897 and #86885) that were closed because developers policy is "this
is an OS malfunction". This may be true, however it is not user friendly. In my
opinion, the most sensitive (mostly with user friendliness in mind) way of
handling this would be (very abstract): 
- check wether there is enough free space in global tempdir, 
-> if true, create tempfile there
-> if false, check wether there is enough free space in ~/.openoffice.org
- -> if true create tempfile there
- -> if false, tell user he needs to clean up either here or there

with current default behaviour, openoffice feels like more ancient versions of
M$'s office: buggy and failing with big documents. It seems to me like this is
an easy-to-resolve issue, so I'm asking the developers team to this. Thanks.
Comment 1 eric.savary 2009-07-26 14:20:23 UTC
Sum up:

While issue 95243 deals with a error message displayed as message box while
saving, this issue deals with the error message writen inside of objects which
cannot be displayed.

So a different UI. That's why I'll keep this issue opened though the main
problem (give a better message) is a duplicate of issue 95243.

Reassigning to Requirements

@MAV: can you please comment on this and on the comments I will do in issue
95243? Thank you!
Comment 2 mikhail.voytenko 2009-07-27 06:51:30 UTC
I completely agree that there is much place for improvement of OOo error
handling. In the mentioned scenario the best way would be of course to provide
the information regarding the original problem.

As for the problem of no enough place in the temp folder, indeed it is a system
problem and OOo should not try to workaround it from my point of view. Although
the office should report the problem in the way that it is clear what goes wrong.
Comment 3 mikhail.voytenko 2009-07-27 07:03:17 UTC
This issue indeed could be treated as a duplicate to issue 95243. It is another
scenario, and leaving it open might be helpful. But from other side, there is a
big amount of scenarios that might be affected by the problem, I am not sure
that we need an issue for each one.
Comment 4 eric.savary 2010-05-04 10:17:23 UTC
Reset correctly to ENHAMCEMENT.
Comment 5 eric.savary 2011-01-28 16:42:15 UTC
*** Issue 116690 has been marked as a duplicate of this issue. ***