Issue 92968 - Dataloss: Document AutoRecovery loads previous version of file instead of backup file
Summary: Dataloss: Document AutoRecovery loads previous version of file instead of bac...
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 3.0 Beta
Hardware: All All
: P2 Trivial with 19 votes (vote)
Target Milestone: OOo 3.0.1
Assignee: Frank Schönheit
QA Contact: issues@framework
Keywords: oooqa, regression, release_blocker
: 93388 94134 97049 97581 97918 98154 101366 (view as issue list)
Depends on:
Blocks: 93339
  Show dependency tree
Reported: 2008-08-20 20:33 UTC by chrisls
Modified: 2009-07-20 15:56 UTC (History)
7 users (show)

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

test files to AutoRecovery process (64.94 KB, application/x-compressed)
2008-10-25 02:59 UTC, majukr05
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description chrisls 2008-08-20 20:33:46 UTC
I am using OOo 3.0 Beta for Mac OSX, BEB300M3 (Build:9328), and one consistent problem I have had is 
that the AutoRecovery doesn't seem to be functioning.  When a crash occurs and I go through the recovery 
process, the file that is loaded comes up as it had been as of the last manual save.  This has occurred 
every time OOo has crashed.  I have generally spent 30 minutes to over an hour on the document and all 
changes are lost.  I looked in the options section under Load/Save, and the AutoRecover was set to save 
recovery data every 15 minutes.  I did not have Automatically Create a Backup checked.
Comment 1 chrisls 2008-08-21 00:19:40 UTC
I deliberately repeated the error by opening an existing document, making changes, then waiting for 
several minutes (I had set the AutoRecover to 3 minutes) then hard restarting my computer.  The 
AutoRecover launched, said it had recovered the document, then said I could open the crash analysis tool.  
I hit next, and the analysis tool did not open, and the document was in the same condition as the last 
manual save.
Comment 2 wtstommy 2008-10-07 02:48:16 UTC
I am also having this same problem (in Linux and Windows, both x64). I did a
little testing. Apparently the recovery is being saved, just not loaded when you
start up the application. You can open the saved recovery information by going
to the location where OpenOffice stores temp data (in my case, /temp). There
will be one randomly generated folder (something like 4bc28e). In that folder
will be a document (or series of documents) with .odt extensions (or whatever
type of file crashed). Again, for me this was 0.odt. That is the document that
should have been opened during autorecovery. 

Make sure you do this before closing OpenOffice, as the act of closing deletes
the temporary folder. 
Comment 3 corigo 2008-10-17 10:41:18 UTC
I am seeing this on Windows XP with OO 3.0 RC 2, 3, & 4. Steps are as follows:

1. OOo hangs/crashes (this has happened to me everyday since I installed RC 3 & 
2. The Explorer window with the file I was just working on is sitting there 
open on my desktop... so I double click on the file to open it.
3. Document recovery comes up. I click recover and I get the last manual save. 
No auto-save data is there. Then the document opens again. So now I have the 
document open twice, once the recovery that didn't recover anything and once 
the double click on the file in Explorer. 
Comment 4 phil_ 2008-10-20 10:27:19 UTC
Really quite a considerable bug, I'm astonished it hasn't even been confirmed yet!

I tested it and found the following behavior:
Instead of the file saved for recovery (default: in folder C:\Documents and
settings\username\Application data\\3\user\backup), the last saved
file is recovered. Additionally, at the point of time of recovery, the file in
the backup folder is deleted!
That means that if OOo crashes, the workaround is to go to the backup folder and
copy the file to your user folder _prior the restarting OOo_.

I really hope this is going to be fixed in 3.0.1.
For most users, especially those not being technical, this is a serious drawback!

See also the discussion here:
Comment 5 hagar_de_lest 2008-10-20 10:31:50 UTC
*** Issue 92968 has been confirmed by votes. ***
Comment 6 phil_ 2008-10-20 12:58:47 UTC
From the bug reports, platform needs to be changed to "All"
Comment 7 Joe Smith 2008-10-20 18:03:20 UTC
I see this on Linux also.

Autosave creates a correct backup copy of the modified in-memory document, in
~/, but after killing (SIGTERM)
OOo and restarting, the recovered document is the last normally-saved version
without the changes in the autosaved document, which is removed from the backup
directory and lost.

OOo3rc4 on Fedora 9.
Comment 8 phil_ 2008-10-21 08:37:06 UTC
Thanks, jes, for the accurate description.
This is exactly the same behavior I see under Win XP as well.
That further supports my assumption that it is a cross-platform issue.
In 2.4.1 it works fine. ==> regression
Comment 9 jbf.faure 2008-10-23 20:39:16 UTC
add me to CC
Comment 10 hagar_de_lest 2008-10-24 21:44:09 UTC
Platform should be changed to All.
Priority should be changed to P2 at least (some activity on the mailing list
about this issue).
Comment 11 majukr05 2008-10-25 02:57:31 UTC
I want to confirm the issue (OOo 3.0.0 rc4 / WinXP)
[test files attached].

It is *not* the AutoRecovery file *.odt-0.odt
(or 0.odt inside the *.tmp folder) which is recovered.
It's the last manually saved *.odt version.

And yes - P2 would be better (to my mind).
Comment 12 majukr05 2008-10-25 02:59:55 UTC
Created attachment 57447 [details]
test files to AutoRecovery process
Comment 13 Rainer Bielefeld 2008-10-28 11:02:36 UTC
I checked for a WRITER document with "Ooo 3.0.0 RC3 Multilingual version German
UI WIN XP: [OOO300m8 (Build9357)]" and can confirm the reported effect. Auto
recovery used the last version of the document, not the backup information from
document in

That's really serious.
Comment 14 Frank Schönheit 2008-10-28 14:51:33 UTC
Can reproduce. Regression compared to 2.4.1 => keyword "regression". Targeting
to 3.0.1, since we're talking about data loss here.
Comment 15 Frank Schönheit 2008-10-28 14:52:44 UTC
fs->as: this is a regression of my change to my change to
MediaDescriptor::addInputStream_Impl, where we now create the InputStream from
the SalvagedFile, if present.

I will revert this change, and see whether I can fix the original problem in
another way.
Comment 16 Frank Schönheit 2008-10-28 21:23:36 UTC
fixed in CWS fix30autorecovery

find more information about this CWS, like when it is available in the master
builds, in EIS, the Environment Information System:
Comment 17 thorsten.martens 2008-11-11 11:10:07 UTC
Checked and verified in cws fix30autorecovery -> OK !
Comment 18 kpalagin 2008-11-12 10:49:55 UTC
*** Issue 93388 has been marked as a duplicate of this issue. ***
Comment 19 orwel 2008-11-25 10:27:45 UTC
I´ve just installed the official OO 3.0.0 relase from and the AUTORECOVERY function still
does not work (e. g. if you kill the proces in Task manager in XP). This bug
should be repaired as soon as possible due OO3 was officially released and this
bug cause data-lost!
Comment 20 ranselm 2008-11-25 10:57:32 UTC
I agree with "orwel", this is a very annoying problem. I already lost my work a
few times and so I want th get rid of this bug. Is there a hotfix available
(e.g. by changing a specified file?
Comment 21 phil_ 2008-11-25 11:08:17 UTC
There will not be a hot fix for this.

You need to wait for release 3.0.1 which is planned for January:

You could also use the developer snapshot, which includes the fix:
However, this entails the risk of other problems, as this is not a release version.

As a workaround, you can manually save regularly.
Or you go back to version 2.4.2
Comment 22 noop 2008-11-25 18:56:52 UTC
OOo-Dev_OOO300_m12_LinuxIntel_install_en-US_deb.tar.gz  	150209 KB  
11/20/2008  	03:35:00 PM

Confirmed as 'Works For Me' on linux (Ubuntu 8.04.1).

@Phil: Regarding no hotfix; the diff files show a relatively minor change:
so would a 'hotfix' not be possible? 

Note: I'm a 'user' rather than a developer so I have no clue as to what such a
'hotfix' would require. However, given the importance of this fix (from
complaints on the user mailing lists) could a possible 'hotfix' be reviewed? 
Comment 23 phil_ 2008-11-26 07:51:54 UTC
@noop: I am not developer either. :-)
As to my understanding, the software structure does not allow hotfixes.
Even if it is a very small change in code, a recompilation is needed which
cannot be replaced by a hotfix.

Maybe someone with a better knowledge can explain the situation more accurately.
Comment 24 Frank Schönheit 2008-11-26 08:01:20 UTC
A "hotfix", or however you call it, would technically be possible, with
different levels of convenience for the user. Finally, it would only require the
fixed library to be placed somewhere for download.

However,, to my best knowledge, did never release hotfixes in the
past. The general politics is to point people to the upcoming micro release
(3.0.1 in this case), which contains fixes for the urgent problems.

When you want to lobby for a hotfix, is the mailing list
which you should subscribe and send your request to.
Comment 25 Rainer Bielefeld 2008-12-09 06:15:03 UTC
*** Issue 97049 has been marked as a duplicate of this issue. ***
Comment 26 floris_v 2008-12-09 09:01:45 UTC
Maybe a warning for defects like this should be mailed to all users, I'm now
getting a newsletter with no information of particular interest to me, and I
often get a mail announcing the new version that I've already installed. So I
don't really need them. But a warning for a bug that can lose me my work would
be much more appreciated.
I'm a volunteer in the old and new community forum and the problem pops up in
both. It's not nice to have to tell people that they lost their work because of
a known bug.

Thank you.
Comment 27 forfsakes 2008-12-18 16:52:18 UTC
Yeah I agree,  a warning would have been nice.

Without getting into details,  this issue has cost me over 10k.  

I would have never used the program if i knew auto-save did not work.

I had it set to every 1 minute for a good reason.

Comment 28 Rainer Bielefeld 2008-12-25 16:56:37 UTC
*** Issue 97581 has been marked as a duplicate of this issue. ***
Comment 29 luisdlc 2008-12-25 18:31:15 UTC
Lets point out something very BASIC:

AUTO SAVE is one thing, and AUTORECOVERY is another and is garbage.

The MOST basic and SIMPLE feature: an AUTOSAVE, is simply non existent in this 
software. All that is needed is a NORMAL autosave. That 
works JUST as if you where clicking the damn 3.5" diskette icon every N minutes.


HOW HARD can it be to just ADD an AUTOSAVE function? If the autorecovery is to 
remain in the software, for the love of god, add a parallel, independent, 
redundant, WHATEVER, but add a proper autosave function.

REALLY how hard can it be, to set an option for every n minutes the program to 
SAVE, no, not to autorecovery save, or save recovery info whatever or any of the
sort, JUST SAVE, normally and PRIMITIVELY SAVE the document?!

Even in the prehistoric times when WORDPERFECT ruled the keyboards, there was a 
SIMPLE but RELIABLE auto save function, that did just that SAVE THE DAMN 
DOCUMENT every N minutes. But lightyears from there, now in the bright future 
of open source, what do we have? autorecovery info something that does not work
at all.

You want to develop some sort of "recovery" technology, hey that's ok, but why 
to deprive the users from a SIMPLE autosave?!

Hey the "save back up copy" option is there right? I don't know who finds that 
useful but COOL, is an option, there, available. WHERE IS MY F*CKING AUTO SAVE?
Comment 30 steveorg 2008-12-26 14:35:16 UTC
Luisdlc - Your complaint is inappropriate on so many levels. First off - this is
a thread about fixing a specific problem. Yours is a totally different issue,
which belongs on the forum. However, the fact that is a complaint and not a
polite "How do I...?" or "Wouldn't it be nice to have a feature that...?" type
of question is beyond me. This is free software supported by volunteers. Its not
a situation where you paid for a feature that wasn't delivered. You come across
as the type of person that yells at waiters and kicks dogs.

You also seem to be the kind of person that expects everything to be done for
them. How about learning how to use features out of your comfort zone? I'm very
new to OOO, but it took me about 10 minutes to figure out how to put together a
script that accomplishes your needs by first recording a save macro and then
going to the documentation to find the control statements. Run it once every
time you load a document that you want autosaved. Here it is:

sub AutoSave
rem ----------------------------------------------------------------------
rem Run this macro for any document that needs an autosave

rem ----------------------------------------------------------------------
rem Set Wait variable to your frequency preference. Use milliseconds. 
rem Examples: 10 minutes = 600000  2 minutes = 120000
nextSave: wait 300000

rem ----------------------------------------------------------------------
rem define variables
dim document   as object
dim dispatcher as object

rem ----------------------------------------------------------------------
rem get access to the document
document   = ThisComponent.CurrentController.Frame
dispatcher = createUnoService("")

rem ----------------------------------------------------------------------
dispatcher.executeDispatch(document, ".uno:Save", "", 0, Array())

GoTo nextSave

end sub

However, I don't recommend using it. As you said, it is a "primitive" feature.
The point of autorecover is to provide the choice of keeping or rejecting edits.
With autosave, you are always committed to changes and you can lose important
work. If all you do is create or edit documents without thinking about the
implications to what existed before, then your work is probably as thoughtless
as your complaint.
Comment 31 phil_ 2009-01-07 08:26:55 UTC
I absolutely agree to steveorg.

Furthermore, the features in OOo do fullfill the same as an autosave function,
however it is defect in version 3.0.0.
Use version 2.4.2 and you are fine.
This function saves to a separate file, and can be recovered without problems
with the autorecovery function.

A simple autosave may be fine for some users.
However for other users it might be a problem. Imagine someone doing deletions
to his document that he wants to revoke. What if the document was autosaved?
Then he couldn't revoke the changes (unless he has a backup copy).
If an autosave to a separate file is made (like it is implemented now), then the
user just has to close the document without saving it, allowing him to get back
the original document version.
Comment 32 niob 2009-01-10 20:14:48 UTC

(Feeling better now.)
Comment 33 niob 2009-01-10 20:18:30 UTC
Re: Phil

"However for other users it might be a problem. Imagine someone doing deletions
to his document that he wants to revoke. What if the document was autosaved?
Then he couldn't revoke the changes (unless he has a backup copy).
If an autosave to a separate file is made (like it is implemented now), then the
user just has to close the document without saving it, allowing him to get back
the original document version."

I suggest that user should use a versioning tool then. From a writer tool, I
primarily expect it to let me write and save my progress, however that progress
may look. If I want to choose from revisions and have the capability to revert
stuff, I use SVN. I don't expect a word processor to ramp up versioning
capabilities, how primitive they might every be. Seperation of Concerns please.

(Thanks for fixing this anyways.)
Comment 34 Rainer Bielefeld 2009-01-11 14:44:56 UTC
*** Issue 97918 has been marked as a duplicate of this issue. ***
Comment 35 Rainer Bielefeld 2009-01-16 18:31:01 UTC
*** Issue 98154 has been marked as a duplicate of this issue. ***
Comment 36 Rainer Bielefeld 2009-02-18 13:27:20 UTC
*** Issue 94134 has been marked as a duplicate of this issue. ***
Comment 37 mmeeks 2009-04-28 09:47:20 UTC
*** Issue 101366 has been marked as a duplicate of this issue. ***
Comment 38 thorsten.ziehm 2009-07-20 15:56:46 UTC
This issue is closed automatically and wasn't rechecked in a current version of
OOo. The fixed issue should be integrated in OOo since more than half a year. If
you think this issue isn't fixed in a current version (OOo 3.1), please reopen
it and change the field 'Target Milestone' accordingly.

If you want to download a current version of OOo =>
If you want to know more about the handling of fixed/verified issues =>