Bug 131165 - Relative paths are just shrouded absolute paths
Summary: Relative paths are just shrouded absolute paths
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.4.1.1 rc
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-05 17:34 UTC by Rainer Klute
Modified: 2020-05-16 18:38 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
demo (12.08 KB, application/x-zip-compressed)
2020-03-07 09:26 UTC, Oliver Brinzing
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Klute 2020-03-05 17:34:12 UTC
Description:
I am saving URLs as relative paths (“Save URLs relative to file system”) in Writer, because I believe it is a good idea to be able to move documents and its referenced resources like images and templates around at will, as long as their relative positions are kept intact.

However, LibreOffice creates relatives paths in a way that effectively inhibits just that. Indeed, these relative paths are really just shrouded absolute paths.

For example, I have a text document in the

/home/user/dir1/dir2/dir3/dir4

directory. The document has a link to an embedded image, which is located in the

images/dir1/dir2/image.png

file. However, instead of using just that relative path (resp. "../images/dir1/dir2/image.png", as seen from inside the document), LibreOffice creates this path:

../../../../../../../../home/user/dir1/dir2/dir3/dir4/images/dir1/dir2/image.png

This is effectively just an absolute path with a prepended (“alibi”) series of ".." elements, navigating to the filesystem root. This nails my document to the very directory it currently it is in. It is not possible to move the document together with its "images" subdirectory elsewhere, let alone check it into a revision control system and have others check it out to very different locations on very different platforms.

Steps to Reproduce:
1. Create a text document and insert an image as link.
2. Save the document.
3. Unzip the document and inspect the content.xml file.
4. Notice that the link is broken as described.

Actual Results:
See description above, e.g., a “relative” path like

../../../../../../../../home/user/dir1/dir2/dir3/dir4/images/dir1/dir2/image.png

instead of 

../images/dir1/dir2/image.png

is stored in the document.

Expected Results:
See above.


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.4.1.1
Build ID: 40(Build:1)
CPU threads: 8; OS: Linux 5.5; UI render: default; VCL: kf5; 
Locale: en-US (C); UI-Language: en-US
Calc: threaded
Comment 1 Oliver Brinzing 2020-03-07 09:26:55 UTC
Created attachment 158462 [details]
demo

i can not confirm this with:

Version: 6.4.1.2 (x64)
Build-ID: 4d224e95b98b138af42a64d84056446d09082932
CPU-Threads: 4; BS: Windows 10.0 Build 18363; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: 

in my example the path is relative:

xlink:href="../dir4/images/dir1/dir2/picture.PNG"
Comment 2 Rainer Klute 2020-03-07 11:29:43 UTC
Perhaps the bug is specific to Linux. I mean, path handling is always an OS issue.
Comment 3 Dieter 2020-05-13 12:32:32 UTC
Regarding to LO Help, LO saves relative paths of URLs as you expect:

"A relative address always starts from the directory in which the current document is located. In contrast, absolute addressing always starts from a root directory" [1]. I'm not very familiar with that topic and so I don't know, if the reported issue is related to corruption in the user profile. To be sure that it isn't, could you please reset your Libreoffice profile (https://wiki.documentfoundation.org/UserProfile) and re-test?

I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present.



[1] https://help.libreoffice.org/7.0/en-GB/text/shared/optionen/01010200.html?&DbPAR=WRITER&System=WIN
Comment 4 Buovjaga 2020-05-16 15:40:43 UTC
Could not repro on Linux. Result is:
xlink:href="../../slide_7.png"

Arch Linux 64-bit
Version: 7.0.0.0.alpha1+
Build ID: bdc8cd060dca8a97ef7970d1c0ab30694930beea
CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: kf5; 
Locale: en-US (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 14 May 2020
Comment 5 Rainer Klute 2020-05-16 18:38:13 UTC
As suggested, I retried it with a fresh user profile – et voilà: Now it works!

Still not intuitive, but thanks for your help!