This is not a bug actually as LibreOffice has the following option enabled by
default:
Tools -> Options -> Load/Save -> General -> Save URLs relative to file system

When you use Insert -> Hyperlink to create a hyperlink to a file in the file
system, Calc saves a relative path from the document to the linked file.

For example, if you are editing /home/user/Desktop/test.ods
and insert a hyperlink to /home/user/Desktop/a.pdf
Calc internally saves the following path: ../a.pdf
(ODS is actually a ZIP archive. You can copy test.ods to test.zip and then open
in with an archiver. There is the content.xml file inside the archive in which
you can see the "../a.pdf" path.)

If you move the spreadsheet to /home/user/Documents/test.ods
the hyperlink now links to /home/user/Documents/a.pdf
(/home/user/Documents/test.ods + ../a.pdf = /home/user/Documents/a.pdf)
although the text shown in the cell still reads /home/user/Desktop/a.pdf
which can be corrected by Insert -> Hyperlink.

This behaviour can be very useful if you have a set of linked files and move
them as a group keeping their relative positions in the file system. If you
want that hyperlinks use absolute paths then disable the following option:
Tools -> Options -> Load/Save -> General -> Save URLs relative to file system

I've tested this in LibO Calc 3.5.0 on Ubuntu 11.10.

Hmm, you right. In version 3.3.4 it does not work, in 3.5.0 work fine.
Thank you very much

LibreOffice 3.5.1.
So, if i save in ods it's works. If i'm save file in xls, hyperlinks is wrong.

Hi Sergey, is it still happen on latest stable release?

Reproduced on Windows 7 with:

Version: 4.1.2.3
Build ID: 40b2d7fde7e8d2d7bc5a449dc65df4d08a7dd38

When saving as XLS or XSLX and moving the file afterwards the link is broken.

OK I think I see what the original author means.

1. create a new document in Calc
2. make sure the option "Save URLs relative to file system" is ticked in "options > save/load > general"
3. add a hyperlink to any file in the same folder as the document, with "ctrl + k > document", set the path to the file and click "OK"
4. save the document as xlsx and close the document
5. move the document and the linked file together in a different folder
6. open the document and try to open the linked file via the hyperlink (ctrl + right click)

Expected behaviour: the relative path allows to open the linked file.

Actual behaviour: the linked filed can not be opened (the path is "/<filename>", with error message "<filepath> does not exist").

The behaviour is as expected if the spreadsheet is saved as odt or xls.

Tested with:
Version: 5.0.3.2
Build ID: 1:5.0.3~rc2-0ubuntu1~trusty2
Locale: en-GB (en_GB.UTF-8)

1. create a new document in Calc
2. make sure the option "Save URLs relative to file system" is ticked in "options > save/load > general"
3. add a hyperlink to any file in the same folder as the document, with "ctrl + k > document", set the path to the file and click "OK"
4. save the document as xlsx and close the document
5. move the document and the linked file together in a different folder
6. open the document and try to open the linked file via the hyperlink (ctrl + right click)

Yes, you are right.

I copied only xlsx file. I did not copy the picture.
If only xlsx file was copied, we would have an error message that the linked file could not be open.

You can close this bug because i did not know the "Save URLs relative to file system" option.

*** Bug 97509 has been marked as a duplicate of this bug. ***

While this page shed some light on my bug report (marked as duplicate), I disagree with how the feature works. The full path is displayed to the user, which misleads just about anyone into thinking the path is absolute.

Now I understand the argument of using relative paths, especially if the images are linked to reduce file size and are generally in the same folder or subfolder as the main document - therefore part of that specific project.

But I will argue the opposite: To avoid data duplication and enable simpler editing of images in multiple documents (such as perhaps company logos or some information that is generally the same), those images are generally saved in a specific place relative to the drive/computer, not the document.



I would suggest the following solution: support both and determine which one to use on the fly (or let user decide):
1) For images that are in the same folder or in a subfolder of the main document, use relative paths.
2) For images that are in a different path altogether - requiring use of "../" - use absolute paths.

Assuming the above, a document with the path "Z:\Header\Somethingspecific\stuff.ods"
and linked images
Z:\Header\Somethingspecific\images\something.jpg
Z:\Header\header.jpg

For option 1, paths should be saved and displayed as "\images\something.jpg", assuming it's something that concerns more or less just that document.

For option 2, paths should be saved and displayed as "Z:\Header\header.png".


My biggest gripe with this is that even if you use relative paths, the absolute path is displayed in the menu, which is misleading and confusing at best - in the very least change the way it's displayed.

confirmed that "save URLs relative to file system" exists in the oldest bibisect I can run in 16.04, so assume inherited from OOo.
Frustratingly, I couldn't even find a code point to grab a hold of for the display of the URL string. Code pointer needed.

Google suggests that Microsoft doesn't support relative paths well in .xlsx. So that may be why .xlsx uses non-relative paths.

Code pointers: include/editeng/flditems.hxx SvxURLField::GetRepresentation()
and the corresponding editeng/source/items/flditems.cxx

Code pointers for the displayed path (comment 12's gripe):
-saving as .ods:  sc/source/filter/xml/xmlexport.cxx writeContent() aFieldVal
-saving as .xls:  sc/source/filter/excel/xecontent.cxx XclExpHyperlink rRepr
-saving as .xlsx: sc/source/filter/excel/xecontent.cxx SaveXml() m_Repr

Using steps in comment 9, I can reproduce the bug in:

Version: 6.3.6.2
Build ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3; 
Locale: en-AU (en_AU.UTF-8); UI-Language: en-US
Calc: threaded

But it works as expected since at least:

Version: 6.4.7.2
Build ID: 1:6.4.7-0ubuntu0.20.04.4
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3; 
Locale: en-AU (en_AU.UTF-8); UI-Language: en-US
Calc: threaded

Marking as "works for me".

Works for me with an Office master spreadsheet and my LO additions. 
I have LO 7.3.6.2.