https://bugs.freedesktop.org/show_bug.cgi?id=42661
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Hardware|x86 (IA32) |All Version|3.4.3 release |Inherited From OOo --- Comment #19 from [email protected] --- Yes, this is an issue. Yes, it is reproducible. Yes, it causes users serious frustration. Please sit back while I explain in detail. Firstly, the symptoms. On Windows, the context menu for files (ie the dialog received when right-clicking a file) has an `Open with` submenu which lists various programs Windows thinks you might want to open the file with. It also includes a `Choose program` option. If I'd like to open, for example, a comma separated values file with LibreOffice Calc but it is not on the submenu, I can choose `Choose program` and a dialog is provided whereby I can select from a list of programs or, if my desired program is not listed, I can navigate to the executable and hit `OK`. Now, normally navigating to a program adds it to the list, then I hit `OK` and the file is opened. However, after upgrading LibreOffice (or even switching from OpenOffice to LibreOffice) nothing will happen after I navigate to and select my desired executable; there is no error message and the program is not added to the list. Literally, nothing happens. Not only is this bewildering to most users... it's extremely frustrating too. OK, now the causes. The short explanation is that LibreOffice includes a version number in it's installation path (ie C:\Program Files\LibreOffice 3.5\program\scalc.exe). Why does that matter? Because Windows registers programs using only the executable name as the key in a variety of places and stores full paths as values; and, because the LO installer/uninstaller does not "clean up" those registry keys. This means after upgrading, say from 3.5 to 4.0, there is a bunch of registry keys with expired values (paths). To be fair, it's not really LO's responsibility to clean up the registry. Oh well. Because the executable name is the same as in the prior version, and keys already exist, Windows does not create new keys when a user performs an upgrade; nor does Windows overwrite/update the existing keys. These expired paths in existing keys are the root source of the symptoms described above: Windows launches the desired program based on the name of the executable the user selects (ignoring the actual path to that executable) and when the path returned via the registry is found invalid, Windows fails silently. Since this is a registry functionality issue, it can be expected to affect Windows users across the globe. I don't know with certainty but do have excellent reason to believe it is an issue on all versions of Windows in all languages. If you want to reproduce this issue, install an older version of LO in a clean VM then update to a newer version. Be sure to use default install paths or you might be cheating. Try to use the `Open with` menu before and after the upgrade. So how can it be fixed? The only successful way (that I know of yet) is to manually find and edit the erroneous registry keys. Searching the registry for the name of the installation folder of the previous version (say "LibreOffice 3.5") will work but that can still be difficult. For example, in fixing one machine, I had to look for "openoffice.org 3", "LibreOffice 3.4" and "LibreOffice 3.5". A more effective method might be to look for the name of the executable, say "scalc.exe". Unfortunately, this requires searching for each program included in LO (scalc.exe, swriter.exe, simpress.exe, soffice.exe, ...). What are some permanent solutions? The simplest by far would be for LO to stop including version numbers in the installation path. This simple step prevents paths in registry keys from 'expiring'. It has the minor drawback of complicating multiple LO installations (but what non-dev user does that anyway?). The larger drawback is that existing symptoms won't be remedied (!). The collary solution is to add version info to the executable name (say, "scalc40.exe" vs "scalc41.exe"). This isn't pretty IMO but it does force Windows to create new keys and, thus, maintain correct paths. A minor side benefit is that multiple installations could coexist peacefully (multiple 'LibreOffice Calc' entries could exist on the `Open with` list). Of course, it would be necessary to include version numbers in the program's display-name too so users can differentiate them on the `Open with` list. More complex alternatives might involve having the LO installer search for and update paths in the registry and the uninstaller find and remove such keys. Such solutions would also (hopefully) correct the problem for users currently experiencing it. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
