Apache OpenOffice (AOO) Bugzilla – Issue 66598
Hyperlinks in recovered document refer to hard-coded location.
Last modified: 2007-08-13 10:25:52 UTC
The frequent crashes of Writer has put me in a very tight spot: During one of the recovery process, the hyperlinks in the original documents are replaced with a hard-coded address, referring to the location of a temporary document (if you hover the mouse on a link, a tooltip shows the path like this: File:///Documen~1/UserName/Local~1/temp/svg6.tmp/FileName.odt#BookMarkName (I have replaced the actual names with dummies in this path.) This is not where my file is stored. Note that the direction of the slashes is reverse, like a web URL. As a result, all the hyperlinks in my 320+ page documents are lost! I have sent the document to MRU. Apart from the analysis, I need help in removing the extraneous part from the hyperlinks, because manual recovery will take a herculean effort!! **** There is a very weird variation in this: One odt file crashes, but subsequently Writer recovers TWO identical documents! In the recovery wizard, both the recovered documents are nameless. One of the recovered documents has grayed out "save" button, while the other has actived "save" button. But I cannot do anything unless I close the copy with the grayed out "Save" button. (If I try to close the other document first, OOo asks me whether to save it. If I select "yes", OOo reports "General input/output error" and does not let me save the document. On the other hand, if I click on the Save" button first, the OOo hangs (shows hourglass endlessly).
I converted the problematic file into pdf. If I click on the defective hyperlinks in pdf file, a dialog window pops up: "This link leads to internet URL...". If I accept this warning, then it waits endlessly (this is natural because the "URL" begings with "file:///", and therefore it is not a valid website adress.) *** I found a dangerous consequence of the variation I mentioned ("two files get recovered"). Therefore, I have raised a separate issue (issue 66724).
SBA->ES: Please proceed.
cc'ing JSI
First I need to reproduce a crash to see what happens. Please help.
ES, 1. The file is with MRU 2. I am using m180 no. Starting with 2.0.3, the crashes stopped. So unable to reproduce (in any case the crashes were random, and not triggered by an event; so you could not control them).
I'm not able to reproduce the crash. So no recover, no problem reproduction.
closed
Did you use an older version of OOo? That crashes often.
Windows XP with SP2 Java build 1.5.0_06-b05 OOo 2.0.3 Observations I made composing a simple web page may be of some relevance to this problem. Create a page with a relative link eg test2.htm View the html source looks fine HREF="test2.htm" In the normal view add a few plain lines to the page and then look at the source again This time HREF="the full file spec" Closing and opening the file restores this to the simple filename I presume a crash while the full file specs were in place might produce the problem
->moorsider: I cannot reproduce what you describe. The reletive path remains relative.
->Raindrops: "crahes *often*" is not something we can reproduce step by step and aborting OOo or let it crash with other known crashes doesn't causes this "temp" recovery. I cannot reproduce what you describe.
Yes, I do understand your problem. Not only that, but each crash does not result into the problem I described. Well, I do not know how to simulate the crash that ALSO leaves the document in a cripped state. Without a debug version, difficult to find the trace!
Even with a debug version... this would mean you would work on your document with a debug version (unconvienent) waiting for OOo to crash *the way it should*. Would you agree to close this issue which you could reopen when: - OOo crashes - you send a crash report - you notice that this last crash has once again produced the temp link? This is the only I see for us to get more info on this.
You are right. Let's close this issue for the time being.
Thanx!
Today I have the same problem with "2.0.2 German version WIN XP: [680m5(Build9011)]" After a crash all (several hundreds) hyperlinks in a document (a kind of index for all our project documents) are damaged in the same way, they look like <file:///C:/DOKUME~1/Eigene%20Dateien/OpenOffice/FIRMA/PROJEKTE/0610_005/korr061005.odt> instead of <file:///C:/Dokumente%20und%20Einstellungen/Rainer/Eigene%20Dateien/OpenOffice/FIRMA/PROJEKTE/0610_005/korr061005.odt> What means: "Dokumente%20und%20Einstellungen" now is "DOKUME~1" "/Rainer" is missing that might be the reason that now all links have become absolute (before the OOo crash they have been relative).
Only one of the documents I had open when OOo crashed is affected: a CALC spreadsheet.Unroftunately it contains confidential inforamtion, but if a developer wants to see it I can provide it with PM. Some weeks ago I also saw that problem in a WRITER document.
ES->MBA: as it happens in Calc and Writer and concerns the recovery: yes a framework issue. Please have a look.
It seems that the base URL we are using on saving the document is set to the temporary location; we must use the "real" URL of the document for it or an empty base URL. It's even better to use an empty base URL as this guarantees that the salvage file will work even if opened directly and not by the document recovery. For this we must fix SfxMedium::GetBaseURL() This method should return an empty base URL in case the pBaseURLItem is not NULL but contains an empty String. Otherwise it wouldn't be possible to hand over an empty base URL via API. As this bug may damage documents considerably I would like to get it fixed in 2.2.1.
I also saw that effect with "2.2.0 Dev. Snapshot WIN XP: [680m7(Build9118)]" and a WRITER master document. After a crash for one of the linked documents the link was destroyed in the reported pattern. No idea for what that might be helpful: The ID of the error report is 'rushub'
No regression -> 2.3
The SfxMedium part is fixed in fwk69 cws. Please use empty "DocumentBaseURL" MediaDescriptor parameter while doing crashsave/autosave.
AS: Done.
AS->OF: Please verify this task on cws fwk69. THX.
OF: No broken links after file recovery in cws fwk69.
OF: After recovery file urls to a document are ok. The same with http urls. OK in src680m225.
*** Issue 75705 has been marked as a duplicate of this issue. ***