Issue 103317 - References to external documents stored as relative URIs are not adjusted during open.
Summary: References to external documents stored as relative URIs are not adjusted dur...
Alias: None
Product: Calc
Classification: Application
Component: open-import (show other issues)
Version: OOo 3.1
Hardware: All All
: P2 Trivial (vote)
Target Milestone: ---
Assignee: oc
QA Contact: issues@sc
Keywords: regression
Depends on:
Blocks: 101565
  Show dependency tree
Reported: 2009-07-03 15:27 UTC by ooo
Modified: 2013-08-07 15:15 UTC (History)
2 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---

proposed fix (against dr68ooo311) (10.93 KB, patch)
2009-07-08 21:28 UTC, kyoshida
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description ooo 2009-07-03 15:27:52 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
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
   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.
Comment 1 kyoshida 2009-07-03 15:45:59 UTC
Ok.  I'll take a look.
Comment 2 ooo 2009-07-03 16:03:24 UTC
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
You'd need the fixes of CWS dr68ooo311 though to make that example work at all..
Comment 3 kyoshida 2009-07-08 16:30:22 UTC
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

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.
Comment 4 kyoshida 2009-07-08 16:43:17 UTC
@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?
Comment 5 kyoshida 2009-07-08 19:19:25 UTC
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.
Comment 6 ooo 2009-07-08 20:13:24 UTC
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.
Comment 7 kyoshida 2009-07-08 21:28:50 UTC
Created attachment 63443 [details]
proposed fix (against dr68ooo311)
Comment 8 kyoshida 2009-07-08 21:37:21 UTC
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.
Comment 9 ooo 2009-07-12 01:05:49 UTC
Grabbing issue.
Comment 10 ooo 2009-07-12 01:07:05 UTC
In cws dr68ooo311:

revision 273910

Slightly changed xmlexternaltabi.cxx lcl_isValidRelativeURL() to also check the
path separator in '../' and end the loop after the first 3 characters.
Comment 11 ooo 2009-07-13 10:59:49 UTC
Reassigning to QA for verification.
Comment 12 oc 2009-07-15 10:21:20 UTC
verified in internal build cws_dr68ooo311
Comment 13 ooo 2009-09-05 17:26:15 UTC
Merged to cws dr69 as dr68ooo311 was not cloned (issue 104156)

revision 275846
Comment 14 oc 2009-09-11 12:47:48 UTC
also verified in cws_dr69
Comment 15 wope 2010-02-10 21:15:25 UTC
testet with OOO320m12