Yep - on numerous occasions I purposely crashed OOo to see how it worked. Under winXP it works as it should.
It doesn't sound as if its the case under your linux flavour. Since it seems repeatable, I would suggest you file a bug and let the dev's work on it. /paul On 5/12/05, James Finnall <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
