Any way to avoid this?
Version: 25.2.5.2 (X86_64) / LibreOffice Community
Build ID: 03d19516eb2e1dd5d4ccd751a0d6f35f35e08022
CPU threads: 4; OS: Windows 7 Service Pack 1 X86_64 (6.1 build 7601); UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-US
Calc: threaded
I’d guess you need to encode the #, if it is part of the filename.
Encode how please? I tried %23 and still it failed.
When you set your path in the top “Path” box, do not encode anything, but make sure to use the full system path (i.e., the path starting with the drive letter D:, not the URL starting with file://). Since you never pasted the path as it is on your system, I won’t try to copy from your image… Basically, the “Open File” button next to the Path box does that correctly for you.
In the “Target” box, there should be nothing.
Then this will be converted to the correct file URL automatically when you press OK, using %23 and %20 and so on, as necessary.
Or, alternatively, you can try to encode it all into a proper file URL - then you have to encode spaces as well.
This is how, I suppose (if I didn’t make mistakes while typing from screenshots), your URL will look like eventually:
file:///D:/ChrisJJ/Observations%20on%20hard%20and%20software/!LibreOffice/Fail%20to%20land%20on%20some%20filename%20cahrs/FAIL%20New%20PDF%20Document%20%23.pdf
I guess you copied the typo of @chrisjj
The first error-message showed “chars”, while he typed “cahrs” later.
.
Maybe not - the new file is in !LibreOffice, the first referenced another folder.
Sure. I tried to be as precise as possible; if a directory is named that way, that’s important.
Thanks. More info found.
The document was created in MS Word and the link address is relative:
LOW hover offers the same path:
LOW Edit Hyperlink alters it for “Path:” but not for URL:
or error:
So, conclusion is that
a) this (but possible not all) hyperlink to relative filename ending with # fails to open in LOW (which might be due to a fault at the Word end)
and
b) LOW’s error shows a path which is apparently false info.
Thanks all.
OMG, Word does not know that hash is a special character in URL? Lol. Well, I don’t even speak about use of backslashes - that is minor, though telling… 
Oh, there’s more: Word itself can’t open the hyperlink it has just created!
100% not our bug.
No idea what is false there. It is 100% the URL that LibreOffice imported (relative + fragment/anchor), generated (adding current path), and tries to open.
OMG, Word does not know that hash is a special character in URL?
This is filepath, so not a URL, right? file:/// not withstanding.
100% not our bug.
That depends on whether the address is valid.
chrisjj:
LOW’s error shows a path which is apparently false info
No idea what is false there.
The path.
It is 100% the URL that LibreOffice imported (relative + fragment/anchor), generated (adding current path), and tries to open.
If LOW did try to open it, being:
then why did it fail, given there is such a file:
?
Yes this is URL. It was filepath, until Word have converted it - incorrectly - into a (relative) URL; it stores the link in the DOCX package’s word/_rels/document.xml.rels - try and see how Word puts wrong “filename” there, ending with %20, without the hash and .pdf. Where are they? Well, open word/document.xml, and find the .pdf as the “anchor” of the hyperlink. Which is what happens, when someone first URL-encodes the filename incorrectly, and then handles special URL characters as the standard says.
It is not.
Because it does not try to open that file, but instead - as the hyperlink demands - it tries to open file FAIL New PDF Document (note that the filename ends with a space, and has no extension), with the fragment (sometimes called “anchor”) .pdf. Exactly what Word stored. The URL looks not like the correct
file:///D:/ChrisJJ/.../FAIL%20New%20PDF%20Document%20%23.pdf
but as incorrect
file:///D:/ChrisJJ/.../FAIL%20New%20PDF%20Document%20#.pdf
where # is not part of the filename, but a special character separating hierarchical path from fragment.
And if you had a correctly encoded URL (as I shown above first), and for some reason, the file that it pointed to would be absent, then the message would look like
“file:///D:/ChrisJJ/…/FAIL New PDF Document %23.pdf” cannot be passed …
Note how the spaces were decoded from %20, but hash wasn’t - because we use a special decoding method here.