https://bugs.documentfoundation.org/show_bug.cgi?id=164862
--- Comment #7 from Mike Kaganski <[email protected]> --- (In reply to V Stuart Foote from comment #6) In fact, I suspect that the log will be OK, and will show the normal registry entries written. And that likely, "That registry value is *not* set" is fact refers to *only one* of the two keys that I mentioned: the "HKEY_CLASSES_ROOT\.ods / (Default)". And the real problem is that there is an override in HKCU for the value *correctly existing* in HKLM. Some background: 1. HKCR is not a normal registry hive, but a blend of two keys: * HKEY_LOCAL_MACHINE\SOFTWARE\Classes * HKEY_CURRENT_USER\Software\Classes and the entries in HKEY_CURRENT_USER take precedence. This allows a user to override the system-level associations; and that means, that once there is the user-level override, the system-level modifications will be ineffective. This is what I suspect to happen here. Looking at HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.ods, I expect to see that the installer (doing the machine-level installation) correctly updates the (Default) value to "LibreOffice.CalcDocument.1"; but looking at HKEY_CURRENT_USER\Software\Classes, we will find a ".ods" entry there, with an own (Default) having some other value, which is effective for the user. And that is not a bug - it's how the system offers flexibility to its users, and users are free to change that - but then there's nothing we can do. It's, as I said, some registry change by the user (or by some of their actions). LibreOffice installer doesn't (and can't) make any changes to the user-level registry. Indeed, that's, again, a suspicion. -- You are receiving this mail because: You are the assignee for the bug.
