James will probably tell you how he did it, but I would think that kill -9 the PID of the soffice binary would probably do it for you.
/paul On 5/12/05, Caleb Marcus <[EMAIL PROTECTED]> wrote: > How did you purposely crash Linux? > > Paul wrote: > > >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] > > > > > > > > > > -- > Caleb Marcus > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
