Apache OpenOffice (AOO) Bugzilla – Issue 103317
References to external documents stored as relative URIs are not adjusted during open.
Last modified: 2013-08-07 15:15:15 UTC
The UI visible absolute URI is not adjusted for references to external documents that are stored with a relative xlink:href URI. This is a regression from OOo3.0.1 Assuming that the document folder is set to /home/you/Documents the scenario to reproduce is: 0. Make sure that Tools->Options->Load/Save->General "Save URLs relative to file system" is enabled. 1. Create any spreadsheet document with some value in A1, save as external.ods and close document. 2. Create a second spreadsheet document. 3. In A1 enter ='external.ods'#Sheet1.A1 4. Note that the formula is displayed as ='file:///home/you/Documents/external.ods'#$Sheet1.A1 and also menu Edit->Links shows the file name as file:///home/you/Documents/external.ods 5. Save as referring.ods and close document. 6. In a shell move both, external.ods and referring.ods, to a different directory, let's say /home/you/somewhere/ 7. Open /home/you/somewhere/referring.ods 8. Note that the formula and Edit->Links still display the URI as file:///home/you/Documents/external.ods It should display file:///home/you/somewhere/external.ods instead. Calculation works correctly and so does refreshing the document. However, the behavior is confusing, and in case a real document /home/you/Documents/external.ods existed additionally, referring that for already cached ranges would not be possible because the cache already resolved the name internally.
Ok. I'll take a look.
P1 wasn't a good idea, it rings too many bells.. lowering to P2. Another quirk: if xlink:href stored an absolute URI, the cache apparently does not return the values but empty instead. Or so it appeared with the attachment of issue 102388 http://www.openoffice.org/nonav/issues/showattachment.cgi/62659/SUMIF.zip You'd need the fixes of CWS dr68ooo311 though to make that example work at all..
Ok. Here is how I'm going to fix this. First, we can't update the absolute path name from the relative name upon file load, since that old path name is used in all of the formula cells that reference the document, as well as in the name of the external doc cache. We need to keep the old path name and use it as a "key" to look up the ID for that document. What we need to do is to store another path, let's call it a "real file path name", and store with it the real absolute path re-created from the relative path when the file path name is requested from the ID. This seems to do the trick. Also, when updating the external document, we should always use the real path to locate the document. And use the old path only when the relative path is absent.
@er: when the "Save URLs relative to file system" is NOT checked, the xlink:href should store the absolute path name for that external document when the document is saved. Do I understand this correctly?
Hmm. Maybe not. The old code reads like the href:xlink values are supposed to be always relative to the own document, at least for the external document cache.
Yes, when "Save URLs relative to file system" is NOT checked, the xlink:href shall store the absolute path name. In this regard OOo3.1 code works correctly, it saves the absolute path in that case, and as long as the documents aren't moved it also appears to be able to read it. Internally for lookups I guess I would always use the absolute path, it leaves no doubt. Just make it relative if requested, e.g. when saving.
Created attachment 63443 [details] proposed fix (against dr68ooo311)
This patch fixes a number of things. First, it fixes the formula string displaying wrong external document paths. It also fixes the problem where absolute URIs were incorrectly stored when saving a new document, whose stored document path is "" (null string). With this patch, you can move around the documents and the formula displays the correct external document paths. You can also modify link to the old external document location etc. Also, when refreshing, the old code tried to open the document at the old path first, then at the new path from the relative URI. The new behavior is to always try to open the document using the relative URI.
Grabbing issue.
In cws dr68ooo311: revision 273910 sc/inc/externalrefmgr.hxx sc/source/filter/xml/xmlexprt.cxx sc/source/filter/xml/xmlexternaltabi.cxx sc/source/ui/docshell/externalrefmgr.cxx Slightly changed xmlexternaltabi.cxx lcl_isValidRelativeURL() to also check the path separator in '../' and end the loop after the first 3 characters.
Reassigning to QA for verification.
verified in internal build cws_dr68ooo311
Merged to cws dr69 as dr68ooo311 was not cloned (issue 104156) revision 275846 sc/inc/externalrefmgr.hxx sc/source/filter/xml/xmlexprt.cxx sc/source/filter/xml/xmlexternaltabi.cxx sc/source/ui/docshell/externalrefmgr.cxx
also verified in cws_dr69
testet with OOO320m12