I too was interested in the autorecovery feature. So I was trying to do
some testing and file locations, etc. under Linux version of OOo Beta
version 1.9.95. I was not able to locate a file called autorecovery.xcu
anywhere under my system. I did locate a file called Recovery.xcu however
and it appears to contain the info described including the directory path
and tree of the file I was editing and the recovery data location as well.
Same relative location except in the ~/.openoffice1.9.95/.... tree.
The Linux version of beta OOo 1.9.95 will create recovery info in the
~/.openoffice.org1.9.95/user/backup in another subdirectory that appears
to be called [docname].odt_#.odt. The # sign represents a number. Inside
this tree are multiple files. If you haven't saved the file at all it
will use untitled1_0.odt for an example.
I tried to do something with this recovery info. But with no success. It
may create it, but it looks like it completely ignores it. But if my
testing process is flawed then probably my tests were not valid.
I configured the autorecovery for 1 minute increments. The feature does
work because I can witness the blue progress bar when it occurs. The date
and time stamps of the recovery files are updated accordingly.
I created a 3 page doc and then waited for it. Reviewed the user/backup
and it was there as the untitled directory tree. Then I just killed all
the soffice processes. Everything disappeared. Verified the recovery
info was still there and the file content.xml actually had the doc
contents in it. Restarted but could not ever achieve anything to use it.
Start a new doc and it was blank. No prompt or an attempt to read it from
what I could tell. Cannot attempt to open any of it because the tree is
hidden and the open dialog does not show hidden directories as available.
Maybe if I tried to type all of it in it might have. But I did not. It
should not be that difficult to use it.
Next I repeated the process, but this time I saved it as testdoc.odt. It
created a recovery tree called testdoc.odt_1.odt. I think it actually did
this prior to me saving because it had the same info was in the saved
file. I killed the processes again and restarted, then retrieved the
file. All of it was there as I had actually saved it. I forgot to make
new changes to it after saving it.
So I made new changes and did NOT save it. After the time period elapsed
it saved a new tree called testdoc.odt_0.odt and it had the additional two
pages I added to the document. So I killed the processes again.
Restarted and opened the document. It only had 5 pages that I had actually
saved. Closed it out and then deleted the 5 page recovery directory from
the prior attempt. Thinking it was using the info from the first attempt
and not the second attempt. Thus leaving only the recovery tree that had
the 7 pages in it. Restarted and retrieved the document but again it only
had the same 5 pages. It did not apparently read the recovery info it had
created to add the other two pages back in. Closed it again and renamed
the recovery tree to the name I had deleted and retried. But still only
the 5 pages I had actually saved.
A really interesting item was that even when I renamed the tree, the info
was not being used but the date and time stamps were being updated on all
the files on each attempt. But the content.xml had all the 7 pages in it
but the document did not. The Recovery.xcu file contained references to
all the backup directories from all the tests I had attempted as well.
So I have had to come the conclusion that it will create the recovery info
and keep it updated. But when the user needs to recover and actually use
it, it appears that it is being ignored.
Perhaps there is a better way to actually test this feature but I thought
it would be sufficient.
Paul, did you actually attempt to create a crash and recovery situation to
see if it was working under the Win platform? From the Linux platform the
recovery structure appears to be very much the same, except for the users
home tree data directory differences.
Perhaps someone else can indicate if it actually works or how to use it. I
was not able to locate any information in the user guide or elsewhere on
any specific directions, so I would think it should be completely
automated on creating a new doc after crashing or opening the doc that was
being worked on during a crash.
Thank you for all your input in regard to this issue.
James
On Wednesday 11 May 2005 21:20, Paul wrote:
There has been some questions of late concerning auto recovery. After
a little digging below is some information that I've found. It seems
that there is one important location and one important file for this
process.
The important location is below:
C:\Documents and Settings\XXXXX\Application
Data\OpenOffice.org1.9.95\user\backup
(where XXXX is your login name)
The files in this directory are the actual copies of the files that
are open at the time and are created/refreshed in line with when auto
recovery has been set for. Files in this directory are usually named
the same as the actual file with an additional "_n" (where n is a
sequential number) appended to the file name before the extension.
There is a single file for each open file. This directory may house
additional files for other uses.
This is the location where you could try to get a copy of your
document if OOo crashed and the original became corrupted. Files
stored in here for auto recovery purposes are independent of 'backup'
functionality.
The important file is:
C:\Documents and Settings\XXXX\Application
Data\OpenOffice.org1.9.95\user\registry\data\org\openoffice\Office\AutoR
ecovery.xcu (where XXXX is your login name)
This file keeps details of which files are open at any point in time.
Important data items within this XML file are the location of the auto
recovery file (which is the path discussed first) and the location of
the actual file (where you actually saved the file). The structure of
this file tends to suggest that the maximum number of open files
accommodated is 71. Any takers on testing this assumption ??
This file is updated independently to the auto recovery timer.
Possibly this is done on save, creation of new file, closure, etc...
So what happens when OOo crashes. Here is where you would really have
to look at the code, but here are my thoughts. A record of all open
files are maintained in the autorecovery.xcu and copies of the
documents (at the last auto recovery point) are stored in the folder
mentioned first. When OOo crashes the autorecovery.xcu is not cleared
of the details of the open files (ie, details of what files were open
when it crashed are still present). Accordingly when OOo restarts it
checks this file and if it finds entries, starts the recovery process
using the files that were saved at the last auto recovery point.
Unsure whether this has been of any use, but hope it has.
/paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
