https://bugs.documentfoundation.org/show_bug.cgi?id=157820
--- Comment #7 from Bernd Wechner <[email protected]> --- The fix is simple. If on an MS-Windows system then: 1) Remove any prefix from a file path that is "\\?\UNC\" 2) Remove any prefix from a file path that is "\\?\" In that order. That's what I do as a work around by opening it with this Powershell script rather than with LibreOffice directly Calc.ps1: param( [Parameter(Mandatory=$true)] [string]$Path ) [regex]$pattern1 = [regex]::Escape("\\?\UNC\") $Path = $pattern1.replace($Path, "\\", 1) [regex]$pattern2 = [regex]::Escape("\\?\") $Path = $pattern2.replace($Path, "", 1) & E:\Util\LibreOffice\LibreOfficeCalcPortable.exe "$Path" (Note I keep a binary for Calc at E:\Util\LibreOffice\LibreOfficeCalcPortable.exe) And then I can associate that by using this registration file patch: Calc.reg: Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\SystemFileAssociations\.csv\shell\OpenCSVwithCalc] @="Open with Calc" [HKEY_CLASSES_ROOT\SystemFileAssociations\.csv\shell\OpenCSVwithCalc\command] @="powershell.exe -NonInteractive -WindowStyle Hidden -File \"E:\\Util\\LibreOffice\\Calc.ps1\" \"%1\"" And no all is good for me, and my shortcut menu. But the bug remains. To be reliably cross-platform all LibreOffice needs to do is update its Windows file path handler (I presume it already handles Windows and *nix paths differently if only because of the \ vs / difference, and the reality of drive letters. Wherever Windows paths are handled, these prefixes simply need to be stripped from the path before continuing (they are Windows way of telling a client the path is long, but not valid parts of a path, and one might rightly argue that is one silly way to communicate this). -- You are receiving this mail because: You are the assignee for the bug.
