https://bugs.documentfoundation.org/show_bug.cgi?id=157820
--- Comment #7 from Bernd Wechner <bwech...@yahoo.com> ---
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.
