File assotiation command (in windows registry) made with this mistake: HKCR\LibreOffice.Docx\shelløpen\command : "C:\Program Files (x86)\LibreOffice 5\program\\swriter.exe" -o "%1" "program\\" should be "program\" Not only for Docx type file. Then I corrected this mistake it was more than 200 changings
Confirming... unfortunately sitting at a Windows 10 Pro build so regedit search is broken for me to be able check the count of instances but ~200 is not unreasonable.
A double backslash was being inserted into file association (shell/new etc.) for all non-native file types that were mapped by the installer to use LibreOffice. Proposed fix is to use an intermediate macro that assembles the <progpath>/program/{app} string to avoid having a trailing backslash mess things up in the preprocessor. Please find patch: https://gerrit.libreoffice.org/#/c/25849/
skswales committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8ab7db320ff158949d2eadaa6e654115201ddf61 tdf#97872 File association in Windows registry It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Just checked this on a Windows 10 box with a 5.2.0rc1 clean install and the errant install affects the shell\new, open, print, printto command path value for all supported formats other than ODF. The patch is probably fine for a new clean install, but question if it will clean-up after prior install with upgrade, or leave the bogus path as a second command. @Jani, Andras either way might be a good idea to backport this for 5.2.0 and maybe 5.1.5
I don't understand the problem. Wasn't it a cosmetic change? Did the double \\ cause any problem? I don't think so.
(In reply to Andras Timar from comment #5) > I don't understand the problem. Wasn't it a cosmetic change? Did the double > \\ cause any problem? I don't think so. Did a quick test run from Command Window, and the extra back slash does seem benign. Functionally it just escapes itself to the shell. So it could be described as cosmetic. Not so clear how the file association(s) behaves with the double \\. Could be equally benign there--certainly there have not been direct complaints. Still, the path being written into Windows Registry is wrong. Probably no need to push back to 5.1, but 5.2.1 target seems reasonable. It is just that getting it in for proper testing requires to use a WRITEREGISTRY=1 install of a daily master--will end up thinly tested.
tdf#53273 implies that people did have problems with the double backslash on Windows 8
(In reply to Stuart Swales from comment #7) > tdf#53273 implies that people did have problems with the double backslash on > Windows 8 Right, but believe Jesús had taken care of the "functional" issues as in screen clip attachment of the original posting for bug 53273 by the 4.1.2 release.
On Windows 10 Ent 64-bit en-US with an install of 5.4.1 release. Checking Windows registry and HKEY_CLASSES_ROOT commands are formatted correctly without the extra back slash. This should have been resolved fixed with Stuart S. commit for 5.3.0 =-ref-= https://gerrit.libreoffice.org/25849