After a default installation of LibreOffice 3.4.2, the .doc file extension is associated with LibreOffice Writer, even if Microsoft Office is installed already. While I'm sure this is fine on a machine without Office available, on a machine with Office installed this is going to cause some complaints. I note that the installer doesn't take the .xls or .ppt extensions, let alone the .docx extension. Suggested behaviour would be to only take the primary association where MS Office is not installed. Windows supports secondary associations in the "Open With" explorer context menu, adding an entry to this would be the best option where Office is already installed - this appears to be the behaviour for the other applications in the LibreOffice suite.
OS: Windows XP SP3 x32 MS Office: 2010 home & b LibreOffice : 3.3.3 and 3.4.2 remove previous installation of openoffice installation : unset box LibreOffice as default to open .doc files. LibreOffice or Openffice unset the file association for all documents ... so i have to go and set the association for each types of file. doc docx xls xlsx pps ppsx etc...
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
LibO 3.4.4 Windows XP Pro SP3 32bit MS Office 2000 and 2003 I had various Microsoft Office programs installed in addition to OpenOffice. OpenOffice was NOT configured to be the default for any file types. I uninstalled OpenOffice and installed LibO 3.4.4. This set the default association for .doc and .oxt to LibreOffice and nothing else. The remaining files types are still pointing to Microsoft Office. I don't recall being asked by the LibO installer to do *any* file association nor ask if I wanted it to be my default office document software. There should be an installer question as to how to handle this. regards rich
Thanks for bugreport Please, verify: in last version of LibreOffice problem remains?
Issue seems to be resolved with 3.5.2. I tried installing via msiexec /qn. MS Office 2000 was installed. Associations were not stolen.
Created attachment 60951 [details] MSI Logs, password is 4321 Seems I spoke too early: I made an administrative install of 3.5.2 and installed from there, using a transform file. Results: 1) On computers joined to my active directory domain: When installing either via: msiexec /i <libo.msi> TRANSFORMS=MyLanguageSelectionTransform /qn ... or via group policy with the same settings, .doc files still get associated with LibO! This happens only for .doc, and not for .xls/.ppt files... 2) On single computers, when installing via the SAME msiexec command line as above, applied to the same administrative image, associations remain correct!!! Puzzled, puzzled. I am attaching a log file from case (2), as case2log.txt. I am also attaching the MSI log from running a silent install on a domain computer, with no transforms applied, that is: msiexec /i <libo.msi> /lvoicewarmupx c:\case3log.txt /qn The .7z file is encrypted with password 4321 (don't ask why, just had to do it...).
If I understand correctly, you do not want to associate MS file formats to LibreOffice at all. Have you tried to use REGISTER_NO_MSO_TYPES property, as described in the README? Like: msiexec /i <libo.msi> TRANSFORMS=MyLanguageSelectionTransform REGISTER_NO_MSO_TYPES=1 /qn Does this work for you?
*** Bug 42473 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > If I understand correctly, you do not want to associate MS file formats to > LibreOffice at all. Have you tried to use REGISTER_NO_MSO_TYPES property, as > described in the README? Like: > > msiexec /i <libo.msi> TRANSFORMS=MyLanguageSelectionTransform > REGISTER_NO_MSO_TYPES=1 /qn > > Does this work for you? This command worked just fine on my domain computers. However, up to a specific LibO (or was it Oo) version, specifying REGISTER_NO_MSO_TYPES was not required at all. If I wanted to grab MS document associations, I just did a REGISTER_ALL_MSO_TYPES=1. If I didn't, I specified nothing at all. What changed? Additionally, in the stock msi I can see that SELECT_WORD=0, as are the relevant Excel and Powerpoint MSI values. Bottomline: what is *expected* to happen when the msi is installed as is? Associate all? Nothing? Word only? If the correct answer is the last one, then it's a feature, otherwise it's a bug as is. Will try to throw in some logs tomorrow.
(In reply to comment #9) > Bottomline: what is *expected* to happen when the msi is installed as is? > Associate all? Nothing? Word only? None of above. It tries to find out if you already have those file formats associated, and tries to keep original associations by default.
Th(In reply to comment #10) > (In reply to comment #9) > > > Bottomline: what is *expected* to happen when the msi is installed as is? > > Associate all? Nothing? Word only? > > None of above. It tries to find out if you already have those file formats > associated, and tries to keep original associations by default. Thank you for the clarification, this might explain why in some cases .doc got associated with LibO. So, this seems like a definite bug, see comment #6 (respective log file case3log.txt). If more info is needed from our side, please let us know.
Stranger and stranger: I made another test on the same system I carried out a test with REGISTER_NO_MSO_TYPES=1 (see Comment 9), this time without setting any variable at all. Just a single msiexec /i <libo.msi> /qn. No problems at all!!! For what it is worth, MS Office XP (2002) was installed on this system. I need to isolate this though, once and for all...
Created attachment 61015 [details] Test scenarios examined under different Office installations After performing a number of tests, I have the feeling that this is not related to whether a system is part of a domain or not. The decisive factor seems to be the version of the currently installed MS Office. I have attached a small table that shows the tests performed. In a nutshell: * In all cases, setting REGISTER_NO_MSO_TYPES worked fine; .doc associations were never stolen, regardless of Office version installed * Problems were found when installing with "msiexec <libo.msi> /qn" on Office 2007, as well as all (except one) of Office 2003 installations. I hope this "investigation" holds...
While this request is logical, I find that the problem can be avoided with full control of the silent installation, as in https://wiki.documentfoundation.org/Deployment_and_Migration.
This is the fourth bug similar to this one that I've seen. I think for Windows users could have a headache if they do the default install and lose file association with MS products. Here is the solution that I personally like best but it's just one of many: https://bugs.freedesktop.org/show_bug.cgi?id=44462&list_id=89889 I'm trying to track down the other ones that I found that are similar to this one
I think I have found it. LibreOffice steals file types from MS Office, if WordPad.exe is also associated to that file type under OpenWithList key. I don't know what was the plan, but it looks like a bug to me. I'll make a patch.
(In reply to comment #16) > I think I have found it. LibreOffice steals file types from MS Office, if > WordPad.exe is also associated to that file type under OpenWithList key. I > don't know what was the plan, but it looks like a bug to me. Are you sure about that? My own testing was performed on the exact same system, a Windows 7 VM (see comment# 13). After this "clean" snapshot was taken, I installed Office 2000, made my tests and then reverted the clean snapshot to make sure that I started over clean. Then I installed the next Office version etc. Bottomline: if your hypothesis is true, then in all cases I examined shouldn't I have the bug exhibited, since in all cases Wordpad is associated with the MSoff filetypes? Or, conversely, if Wordpad was not associated with these files, the bug should appear in no tests at all. This was not the case of my findings: I had inconsistent results and the affecting factor seemed to be the Office version installed. If you have something to test (your patched version), I'd be more than happy to check it out, since I've kept snapshots of the VMs with the different Office versions.
(In reply to comment #14) > While this request is logical, I find that the problem can be avoided with full > control of the silent installation, as in > https://wiki.documentfoundation.org/Deployment_and_Migration. Update: issue persists in 3.6.1. Specifically, installing via gpo on Windows XP Pro systems with MS Office 2002 already installed, and with REGISTER_NO_MSO_TYPES set to true (REGISTER_NO_MSO_TYPES=1) *still* destroys the association with .doc: now they are set to open with wordpad. Excel file associations were not affected.
(In reply to comment #18) > Update: issue persists in 3.6.1. Specifically, installing via gpo on Windows XP > Pro systems with MS Office 2002 already installed, and ... One correction, program was installed alongside Office 2003. Checking comment# 13, one can see in the attachment that Office 2003 is one of the MS office environments where this bug is exhibited.
Andras Timar committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e2b1a7e4e4d9bfc32aab9921c30a6e40e08b8210 fdo#39791 do not steal .doc association from MS Word 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.
This is still ASSIGNED. Can those affected confirm this is SOLVED?
I think I solved the problem described in comment 16. This bug has many comments, and they are confusing. I'm closing this one.
*** Bug 47483 has been marked as a duplicate of this bug. ***