Issue 7597 - File|Reload does not report errors
Summary: File|Reload does not report errors
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: OOo 1.0.0
Hardware: Other Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2002-09-09 04:42 UTC by sgp
Modified: 2017-05-20 11:19 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 sgp 2002-09-09 04:42:01 UTC
If, after a .sxw file is opened in, that file changes on disk
(eg, a developer unzips content.xml then re-zips to same_filename.sxw),
File|Reload will *silently* fail if the new document is not valid.
It will take the cursor to the top of the current document, giving the
impression that the file has indeed been reloaded.

I encountered this problem because I am writing an application which creates
.sxw files. I was trying various features, reloading the file each time to check
if the change worked as expected. The change appeared not to work, so I tried
another, and so on. After half a dozen changes, crashed, and I found that
I needed to keep on backing-out my changes until I found the bug in my code.

This is a pain for developers trying to test that their applications
work with the file format. It is also, presumably, a pain for

The workaround is to use File|Close, followed by File|Open, but this is a pain,
especially since because closing the last document closes the application.
Comment 1 sgp 2002-09-09 04:47:30 UTC
Sorry, the mention of crashing was not very clear - I'm not
sure why it crashed, but the crash meant restarting, re-loading
the document (using File|Open), which was the first time said
that there was a problem with the document.
That bug (in my .sxw-creation code) had been made many revisions
before, but File|Reload had been silently failing, so it was only when
the crash forced me to use File|Open that I found the bug in my own code.

File|Reload should perform the same checks, and issue the same errors,
as File|Open.
Comment 2 stefan.baltzer 2003-03-31 17:25:06 UTC
I agree that File-Reload should behave EXACTLY like
file-close-file-open. Confirming issue.
-> Eric: Please have a look. 
Comment 3 eric.savary 2003-11-05 18:26:42 UTC
ES: OOo creates a tmp file when the doc is opened and works on this
tmp file the whole time. Not on the file on your home directory.

ES->TM: for it's a framework issue, please evaluate.
Comment 4 malte_timmermann 2003-11-10 10:19:01 UTC
Seems ES wanted to send to TM, not to MT (me)...
Comment 5 thorsten.martens 2003-11-10 13:53:05 UTC
TM->MBA: Please have a look. As far as I know, a reload is surely not
the same as a file-close / file-open operation for some reason. Maybe
this is more a wish for a change in a feature or an enhancement than a
real defect.
Comment 6 sgp 2004-07-02 03:32:28 UTC
I don't agree that this is an RFE; File/Reload should produce the same result as
File/Close followed by File/Open. 

What is the purpose of File/Reload?

The end user does not know or care that SO/OOo works on a /tmp file; that is an
implementation detail. The functionality of File/Reload must have a defined purpose.
From ES's comment, that purpose appears to be "no purpose".

As a user, I would expect File/Reload to re-visit the file I had specified to be
opened (not some temporary file SO/OOo had chosen to create) and, effectively,
close the current file "in memory" and go back to my "staroffice somefile.sxw"

Removal of the "File/Reload" menu item is an acceptable action.
The only other action would be to make the function work as rationally expected.
Comment 7 sgp 2004-07-02 03:45:29 UTC
The existing definition from es (Nov 5 2003) sounds more suitable for an
"Edit/Undo Changes" application than a "File/Reload".

I do not find "File/Reload" essential, merely useful.

Reassigning this as "Edit/Undo Changes" sounds more appropriate for this
"feature" as currently implemented, unless I am missing something here.
Comment 8 Mathias_Bauer 2006-02-10 12:24:58 UTC
The code for reload is a nightmare because we try to keep the view though we
have thrown away the document (otherwise we couldn't open the file for writing!). 

We could get rid of a bunch of issues by replacing the current procedure by a
simple"close/load" procedure (of course with the "side effect" that the document
closing will be *visible* to the user). Something like temporarily switching the
window to "backing mode" and then reopening the file is what I would want to do.

I definitely would opt for this change. Frank, please give a comment from the
user experience standpoint. In case you agree the target could be set to "3.0"
Comment 9 frank.loehmann 2006-02-10 15:00:28 UTC
FL: The "Reload" function is no hard requirement for an office application from
my point of view and the competition does not offer this function at all. I
think this requirement comes from  past times when SO was a "web browser" many
years ago. Removing the function might be an option but I have no data to back
this decision and so we maybe disappoint some "normal" users used to this
functionality. Furthermore I do not understand that is is possible to exchange
the original document while a tmp copy of the document it is loaded. I thought
that even the original document file must be locked as long the copy of the
document is opened somewhere. Disabled file locking on a Linux system?

So I propose to rework the current implementation to the simple"close/load"
procedure like MBA has described above. I have no problem with closing and
reopening the document in front of the backing window (is this possible even if
it is not the last doc?) and that this is visible to the user - this is feedback
and indicates what is currently in progress. Even the cursors position must not
be the same after reloading, because the current part of the document might not
be contained in the original document at all and again it is feedback for the
reload being in progress. But the container attributes (window position, size,
document position inside the window and the document zoom level) should be
restored from recently closed working document from a usability perspective.

I would agree to set this to OOo 3.0 (to simplify internal doc handling), even
if I think this is not the most important issue, because normal user will have
no problems with the current implementation.
Comment 10 sgp 2006-02-10 23:14:24 UTC
WRT the file-locking issue, it's nothing to do with file locking AFAICT. On a
standard Ubuntu "Breezy Badger" install (OOo 1.9.129), using  reiserfs (mounted
"rw,notail"), the following simple test:
- Create test1.odt containing the text "Test One"
- Create test2.odt containing the text "Test Two" (or indeed a garbage file)
- Close test1.odt and test2.odt
- File/Open test1.odt
- $ cp test2.odt test1.odt    (or 'echo foo > test1.odt')
- File/Reload
- Observe that test1.odt ("Test One") is still displayed
Comment 11 Marcus 2017-05-20 11:19:38 UTC
Reset assigne to the default "".