| Summary: | Links to Windows shares become corrupted in XLSX after save | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Aron Budea <aron.budea> |
| Component: | LibreOffice | Assignee: | Szymon Kłos <szymon.klos> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | mikekaganski |
| Priority: | medium | ||
| Version: | 4.0.0.3 release | ||
| Hardware: | All | ||
| OS: | Windows (All) | ||
| See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=111957 https://bugs.documentfoundation.org/show_bug.cgi?id=45435 https://bugs.documentfoundation.org/show_bug.cgi?id=118990 https://bugs.documentfoundation.org/show_bug.cgi?id=121472 |
||
| Whiteboard: | target:6.0.0 | ||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 104742 | ||
|
Description
Aron Budea
2017-08-17 08:53:43 UTC
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
|