Bug 97872 - File association in windows registry
Summary: File association in windows registry
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Whiteboard: target:5.3.0
Depends on:
Blocks: File-Association
  Show dependency treegraph
Reported: 2016-02-15 11:30 UTC by Eugene
Modified: 2017-09-22 17:18 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Eugene 2016-02-15 11:30:53 UTC
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
Comment 1 V Stuart Foote 2016-02-15 16:17:05 UTC
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.
Comment 2 Stuart Swales 2016-06-02 23:11:58 UTC
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/
Comment 3 Commit Notification 2016-06-23 09:56:57 UTC
skswales committed a patch related to this issue.
It has been pushed to "master":


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:

Affected users are encouraged to test the fix and report feedback.
Comment 4 V Stuart Foote 2016-06-23 14:23:41 UTC
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
Comment 5 Andras Timar 2016-06-23 14:43:06 UTC
I don't understand the problem. Wasn't it a cosmetic change? Did the double \\ cause any problem? I don't think so.
Comment 6 V Stuart Foote 2016-06-23 15:27:29 UTC
(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.
Comment 7 Stuart Swales 2016-06-23 17:28:12 UTC
tdf#53273 implies that people did have problems with the double backslash on Windows 8
Comment 8 V Stuart Foote 2016-06-23 18:02:05 UTC
(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.
Comment 9 V Stuart Foote 2017-09-22 17:18:28 UTC
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