Apache OpenOffice (AOO) Bugzilla – Issue 93071
Autorecover: changes to auto-recovered file lost after closing OOO
Last modified: 2009-01-08 13:37:11 UTC
This is a bit hard to describe. Try the following: - Work on a database. Provoke a crash, e.g. by saving a query under a new name that already exists either as table or query (using a current but for the test :)). - Crash recovery will get active and restore the database. - Changes you made to the file before the crash will be lost - that's sad, but that's not the bug I am refering to. - At this point crash recovery will not tell you, that you are currently not working within your original database file but with a temporary file named databasename_01.odb which is stored in the user-profile in .../databases/, the same folder as the biblio database. - Keep working a bit in this recovered database. - Save your changes and quit as normal. - Reopen your original database. 1. Changes you made after datag-recovery will not be there. 2. The temporary recovery-file in the user-profile is gone. So your latest work is lost. Apparently the crash-recovery mechanism doesn't write the temporary recovery-file to the original database but continues using the temporary file. Yet after closing this file it is deleted and with it all work since last crash recovery. Hope this was understandable Best .r.
do you use the internal (hsql) database or connect over odbc/jdbc etc.?
I use MySQL with jdbc. I assume this issue has to do with the earlier, general crash-recovery issue on OSX. It's quite difficult now to reproduce, also since the easy ways of crashing Base have gone :). I'd propose setting this issue to sleep - myself I don't have the time at the moment to try to work out exactly what happens. Most probably its gone anyways by the fixing of the general crash-recovery issue anyways. Best .p.
I am using PostgreSQL with JDBC now and OO3 release with leopard. The issue is still there. When this happens (which is admittedly very rare) it can destroy a lot of work unrecoverably. I repeat a somewhat rephased description of the issue, maybe I couldn't make myself understood well the last time: - crash a database (well, we need a crash). - restart and let autorecovery do its job. It should open the database you were working in for you (at least that is what appears to happen). - create a new query and save it. - close the database. - reopen it: the query you created after the crash-recovery is gone. This is, because crash-recovery does not open your original database for you, but a copy (called something like dbname_01.odb). After crash-recovery you work in that temporary file (without knowing it), all you modifications are saved to that file. When you close OO, this file is deleted and your work gone. The original file will open as if nothing had happened. One doesn't meet tis issue too often, because Base doesn't crash too often (for me), but if it happens it can be quite catastrophic... I posted this issue to the dba-users-mailinglist and one other user reported that he had also met this issue on OSX. I do find this a serious problem, so I raise priority and reassign to dbaneedsconfirm. Hopefully somebody will react.
- This issue is still there in m37 - It is specific to Base. The same thing does not occure e.g. in Calc. - It has been confirmed a second time (by Drew Jensen) a) to exist and b) not to be Aqua specific. - I find it is not always cleanly reproducible in OO3 but it seems to be so in m37. Additionally you are warned in m37, because the window-bar of the main base-window does indicate that one is currently using the temporary file named dbname_01.odb (and not the original database-file, as one would expect).
@pancapangrawit: In your description > - crash a database (well, we need a crash). > - restart and let autorecovery do its job. It should open the database you > were working in for you (at least that is what appears to happen). > - create a new query and save it. > - close the database. > - reopen it: the query you created after the crash-recovery is gone. , do you save the database (after saving the query and before closing the database)?
If I save the document between saving the query and closing the doc, then I cannot reproduce the problem - upon next open of the document, the new query is there. What indeed looks suspicious is if you toggle the "Load URL" toolbox item to be visible in the standard toolbox, then it displays the name of the temporary document, from which the original document has been recovered. However, so far I didn't find a negative impact of this, saving still seems to happen to the proper file. All of this done with DEV300m37 on WinXP.
I am sorry, I have difficulties myself at the moment, to reproduce this issue. Maybe I have to wait until a real crash happens. Currently I kill (OSXs 'Force Quit') base to trigger autorecover, and the problem doesn't seem to occur. On the other hand I am absolutely sure, that this does occur under some circumstances and at least two other users have observed something similar. Drew Jensen confirmed the issue for 3.0 with two comments: - if you turn off auto-recovery information auto save this will stop happening. - I haven't tried this with 3.0.1 pre-release so can't say if it's already fixed. Currently I cannot toggle the behaviour the way Drew indicates with his first point... So currently I see no alternative to waiting until this happens again. Sorry...
Ok, closing in, hopefully: I have had the described issue again. I was after a full fledged crash which I actually triggered in Calc (by inserting fields, which is a efficient way in m37 if u do it repeatedly) while Base was running as well. In this crash autorecover got active before the restart, stored files to disk before closing down, and then automatically restarted OO and offered recover files (in previous attempts to trigger the problem I had simply killed base - in that case autorecover only gets active on restarting OO, it doesn't save anything). I did consciously save both the query into the (autorecovered) database and the database itself after the query was closed. The query was gone after I restarted the original database-file (from the file-manager). Best .r.
okay, can finally reproduce. There's a number of important points, the following sketch is a minimal description, I think: - start OOo (important: do not use -norestore :) - open a DBDoc - modify this DBDoc important: do *not* save it - crash OOo, e.g. by executing the following Basic macro: createUnoService("com.sun.star.frame.DispatchHelper"). _ executeDispatch(StarDesktop, ".uno:Crash", "", 0, Array()) important: The crash *must* be "soft" enough that the crash reporter can be started and successfully run => an error box pops up, information about the crash, and saying that the DBDoc will be recovered - confirm the box with OK - restart OOo (if not done automatically) => the recovery wizard pops up - allow the wizard to recover the DBDoc - make modifications to the DBDoc - save and close the DBDoc - close and restart OOo - re-open the DBDoc => the most recent changes are lost In fact, if you look into the file history (menu: File/Recent Documents), you'll notice a DBDoc entry with a strange "temporary" location - this is what you actually worked on after the recovery, not the original document.
The good news is: This does not happen anymore in CWS dba31g, which is the latest and greatest towards OOo 3.1. Resolving as FIXED. pancapangrawit, if you have the chance, please verify this once CWS dba31g is integrated (http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fdba31g), and the next milestone release becomes available.