The following two commands work as expected: libreoffice file:///path/to/file.odt libreoffice file://localhost/path/to/file.odt However, this command does not: libreoffice file://my-real-hostname/path/to/file.odt LibreOffice's splash screen appears for a short while, then it disappears and nothing more happens. LibreOffice should open the document (at least when the specified hostname indeed matches the current machine's). Or, if something goes wrong (e.g. the hostname doesn't match, if LibreOffices cares at all [note that e.g. Firefox or Chrome don't]), it should present an explanatory error message. Note that I'm testing this on a private use standalone laptop, that is, I have no domainname set, the commands "hostname" and "hostname --fqdn" both report the same dotless string. I'm using LibreOffice 5.3.1 as shipped by Ubuntu Zesty 17.04. ----- How I discovered this and why this might (hopefully) soon become a more frequently hit issue: I've recently implemented a new feature in gnome-terminal that allows web-like hyperlinks in the terminal emulator, that is, arbitrary user visible text with a target URL which is opened on Ctrl+click. The iTerm2 terminal emulator (macOS) has also implemented this very same feature. We're hoping for this to get some recognition and support by various utilities. I've also hacked up a patch to the "ls" command which linkifies ("file://...") all the entries it prints. It's a great convenience feature for quickly opening files. In the feature specs, we strongly advise utilities that produce "file://..." hyperlinks to fill out the hostname, and correspondingly, terminal emulators to verify that the hostname indeed matches the current host's. This is so that over ssh you cannot accidentally open the local counterpart of a remote file. Alas due to this bug, .odt and similar files cannot be conveniently opened with a Ctrl+click over the output of a "ls --hyperlink=auto" [patched ls] command. For further details, please see https://bugzilla.gnome.org/show_bug.cgi?id=779734 (especially comment:120) https://bugzilla.gnome.org/show_bug.cgi?id=781800 https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
Reproduced. Arch Linux 64-bit, KDE Plasma 5 Version: 5.3.2.2 Build ID: 5.3.2-1 CPU Threads: 8; OS Version: Linux 4.10; UI Render: default; VCL: kde4; Layout Engine: new; Locale: fi-FI (fi_FI.UTF-8); Calc: group
Looks like this request is somewhat moot, due to thread comment: > > Given that gnome-terminal verifies that the hostname is the local host and > > refuses to open otherwise, I'm wondering: Should it work around these > > problems by removing the hostname before opening the file: URI? > It would make this work and I don't see a downside so my answer would be yes. But anyway, code pointer... soffice file://JL-1804/testFile.docx ucb/source/ucp/gio/gio_content.cxx:392: ignoring GError "Failed to mount Windows share: Connection refused" for <smb://JL-1804/testFile.docx> #include <osl/socket.hxx> osl::SocketAddr::getLocalHostname()
> Looks like this request is somewhat moot, due to thread comment: Just because we applied a workaround, it doesn't mean that LibreOffice shouldn't adhere to the standards and shouldn't fix its bugs. In fact, I'd happily drop our workaround if that's what makes LibreOffice fix this in the foreseeable future :)
Please note the interoperability issues with Windows shares (SMB). On Windows, a path like \\server\share\path\file.ext translates to URL like file://server/share/path/file.exe; and the share is anything in the server's filesystem that made shared, most often not at any drive root, and possibly named differently than underlying filesystem directory - so in general, accessing \\localhost\share\path\file.ext, you are in reality accessing d:\mydir\someotherdir\shareddir\path\file.ext. Given that file references in documents may be stored using both native path and URLs, it's essential that LO treats file URLs created on Windows properly when opened on, say, Linux. So some really clever solution required here.
I'd even close this as NOTABUG, since it's generally impossible to tell an SMB URI from another file URI as per RFC. So LibreOffice standardizing on treating file scheme with authority as SMB is just a possible (and unambiguous) variant. This is simply something that needs documenting.
RFC 8089 (https://tools.ietf.org/html/rfc8089) says: A file URI can be dependably dereferenced or translated to a local file path only if it is local. A file URI is considered "local" if it has no "file-auth", or the "file-auth" is the special string "localhost", or a fully qualified domain name that resolves to the machine from which the URI is being interpreted (Section 2). I can't see how it leaves room for alternatively accessing the local file via SMB or other means.
(In reply to Egmont Koblinger from comment #6) Please don't make it look simpler than it is. First, look at appendix E.3. UNC Strings. It is, of course, not normative, but it represents the status of the things as they are at the moment of the standard writing (2017). And - surprise - by that moment, some few existing Windows users had used file: schemes to reach their Windows (SMB) shares for some 30 years... and had their few documents with those usages. And then, there was a document (which you refer to) named "Standard for exchanging file: URIs", which gave specifications explicitly on file: URIs on *UNIX*, without considering if this translates correctly to other systems. And then, I read that someone discusses if it's OK to bind to that spec (using gethostname()) or RFC (which uses FQDNs, because that naturally scales better to other systems), and declares that it's unnecessary to follow the unambiguous words of RFC on the grounds that it fits his Linux habits more (or, rather, that for *some specific usages*, that would be simpler). And then that person starts to question if other deserve to continue using their established (during decades!) de-facto standards, which were "obsoleted" by recently-issued RFC of the "Proposed Standard" status, which additionally mentioned the existence of that practice. Well - of course, the adverse effect of making billions existing documents using that established practice is insignificant.
My intern and I were just investigating this together. We noticed that file://localhost/ is turned into file:/// and wondered if it would be easy to do the same thing with file://<getlocalhostname>/. We found that the change was made by the CTOR INetURLObject aObj( OUString aName ); So, even if there is agreement to move forward, then it probably won't be an easyhack after all.
(Note <https://gerrit.libreoffice.org/67372> "Remove dubious Linux-only file: -> smb: conversion from INetURLObject". Merging that would tangentially affect this issue, in that opening <file://hostname/path> URLs would no longer internally convert them to smb URLs on Linux, but would still fail.)
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/f90e26b6313a2a7e492337f5957e49f5a512e5e7%5E%21 tdf#107461: For Unix-like OS, support file://<hostname>/... URLs It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks for this fix! Part of my original report was that LibreOffice just silently failed to start up, didn't even present an error dialog. I'm wondering, have you also fixed this, or is this not relevant for non-Unix systems?
(In reply to Egmont Koblinger from comment #11) > Part of my original report was that LibreOffice just silently failed to > start up, didn't even present an error dialog. I'm wondering, have you also > fixed this, or is this not relevant for non-Unix systems? No, I didn't address that here in any way. LO silently discarding such command-line requests that it can't handle is a long-standing well-known issue (inherited from OOo). So well-known to us developers that we hardly notice any more. ;) If you like, you can file an issue specifically for that---unless there is already an existing issue for it.