Preparation: - Have a Windows share, and another computer with LibreOffice that will access (and write to) the share. - Add a file, let's say a DOCX (to be the target for a link) in \\<share>\<path1>\linktarget.docx - In \\<share>\<path2> (so, a different path) create a new XLSX spreadsheet, and add a link inside that points to \\<share>\<path1>\linktarget.docx The way to do that is to open Insert -> Hyperlink..., switch to Document and enter \\<share>\<path1>\linktarget.docx in Path: field and click OK. It can be verified that the OOXML archive contains the link in file xl\worksheets\_rels\sheet1.xml.rels in the form of 'file:///\\<share>\<path1>\linktarget.docx' (this is the same format as if it had been created in Excel). Now reopen the spreadsheet, and save it once again as XLSX. => The link becomes 'file:///<path1>\linktarget.docx'. It can be verified by hovering over the link after reopening the spreadsheet, or by looking at the file mentioned above inside the archive. The link is incorrect, and doesn't point to the document. The behavior probably depends on setting 'Save URLs relative to file system' in Options -> Load/Save -> General, but this is not a correct relative link, that should start with "..\.." until the common part/root of path1 and path2 is reached. Interestingly despite the setting 'Save URLs relative to file system', the initial save saves an absolute link. Ultimately I don't think links to network shares should ever be saved as relative links, even if they're on the same share, or even if they're mapped to a local drive, regardless of the relative/absolute setting. Observed using LO 5.4.1.1 & 4.0.0.3 / Windows 7.
I touched this in the deep past, but don't remember details unfortunately; but overall, we should treat the samba shares (\\server\path\to\file.ods) like URLs, and never relativize that. Having said that, LibreOffice internally works with absolute URLs, so when the 'relativization' is on, it has to do heuristic to reconstruct the relative paths; but that should be omitted for samba shares. The commits I came up with in the past were these: https://cgit.freedesktop.org/libreoffice/core/commit/?id=6423f447db9130673089b5057fd174d321b5de5a https://cgit.freedesktop.org/libreoffice/core/commit/?id=7fe1706d431d8a4e366a2999726d75fc641d05b0 Either they regressed, or we have another corner case here I think...
I tested the behavior with local linking (eg. when the file's location is something like C:\<path1>\linktarget.docx) and DOCX and ODS format as well. 1. Link in ODS (local and Windows share) ODS stores proper relative link (so what it takes to go from path2 -> path1) right from the first save. Of course in case of Windows shares this is not what we'd like. 2. Local link in XLSX It's the same as the remote link: upon first save the absolute link is saved in the file. Upon subsequent save it's replaced with an incorrect, 'file:///<path1>\linktarget.docx' kind of link. In this case the link works (unlike with remote shares), but this is not a proper relative link. 3. Link to Windows share in DOCX The link is saved slightly differently, as 'file://<share>/<path1>/linktarget.docx' (note the backslash vs. slash difference). This format persists after the second save, too (the link stays absolute), and thus the link keeps working. On the other hand, local links are saved similarly, and not as relative (or rather, honoring the absolute/relative setting). Unfortunately each of these are wrong under certain circumstances...
Note that comment 2 is just to offer a broader perspective on the situation, only Windows share links in XLSX (and possibly in XLS, I haven't checked those) are important now. Additionally there might be merit in fixing the code that creates broken relative links in XLSX (2nd case in comment 2).
Szymon Kłos committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=51e610e584e09ecdec4cbc5c7c550bc806d7ee1c tdf#111876 Save correct relative links in Calc It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Links seem good after the fix, thanks Szymon!
+ aData.maBasePath = "file:///" + aData.maBasePath.replace('\\', '/'); Hardcoding like this is invalid. Normally Protocols should have only two slashes. In Windows a third slash is added IF there is no host specified. The result of this command under Linux is that there are four slashes (file:////home/etc) suggested replacement code https://gerrit.libreoffice.org/51637