Created attachment 85393 [details] Installation assistent When upgrading 4.1.0 to 4.1.1.2 i got a notice about a process that was using files and needed to be closed before installing could continue. See attached screendumps (unfortunatly some are in Dutch This process is not an application that i can 'normally' close. So, i do think that i should not get this notice Installation should continue, and a messag (probably about a reboot that is required should follow) ;( The information on process 7740 is: C:\Users\Luuk>tasklist /V /FI "PID eq 7740" /FO csv "Image Name","PID","Session Name","Session#","Mem Usage","Status","CPU Time","Window Title" "explorer.exe","7740","Console","1","95.264 K","Running","0:00:13",".NET-BroadcastEventWindow.2.0.0.0.2e0c681.0"
*** Bug 71163 has been marked as a duplicate of this bug. ***
I include here the bug report from Bug 71163, which I think is clearer: Chris 2013-11-02 14:24:55 UTC When I installed the new version of LibreOffice on my Windows 8.1 desktop, it will pop up during the validating install process stating that you have to close explorer.exe to continue. If you tell it to ignore it, it will not proceed until you close it. I had to go to task manager and kill explorer.exe to finish installing. Then, you have to re-launch explorer.exe to be able to use anything in windows 8.1 . I encountered the same in a recent upgrade with LibO 4.1.2.3 on Windows Home Premium 64bit. I'm marking importance as high as this stumps novices, and gives LO a bad reputation.
Might be related to Bug 56007.
Andras, any idea why this happens? does it happen only on Windows 8.1 or older versions too?
Happens to me on Windows 7 HP 64-bit.
(In reply to comment #4) > Andras, any idea why this happens? Unfortunately I couldn't reproduce it. It can be related to shell extensions or indexing service. For example the shell extension is generating a thumbnail of a file which is on a slow drive (reading 1 byte at a time, see bug 56007), therefore Explorer holds that dll during uninstall. Hopefully the bug will not be reproducible with 4.1.4. On the other hand, if user ignores this warning, the uninstaller will ask for a reboot in order to complete uninstall process.
Created attachment 91506 [details] installation wizard error dialog
I also am having the problem same as described in by Luuk below. Error dialog is also the same (in English though). I am trying to update from 4.1.3.2 to 4.1.4.2. My system is Windows 64 HP AMD 64-bit. While there is a work-around, I really do like to monkey with installations in case there is some secondary effect. I also give this high importance, as I have not see such a terminal error in other software installation. I am willing to wait until next version, hopefully this can be fixed.
Sorry, I meant I really don't like to monkey with installations.
Sorry, I also meant Windows 7 HP, AMD 64-bit.
(In reply to comment #8) > I also am having the problem same as described in by Luuk below. Error > dialog is also the same (in English though). > I am trying to update from 4.1.3.2 to 4.1.4.2. > My system is Windows 64 HP AMD 64-bit. Thank you for reporting. However, please do not "update" the version number. It's suppose to show the earliest version the issue is occurring. I'm changing it back to the original. The matter seems to be inconstant. When I upgraded to 4.1.4.2, the matter didn't arise at all. The difference I notice is that Explorer is set not to show thumbnails. So, Andras's guess is probably correct. I wouldn't want to label this "notourbug" though, since the issue don't occur with installations of (most) other programs. Meanwhile, I encourage affected ones to test. In Windows Explorer, go to Organize > Folder and search options > View tab. Tick "Always show icons, never thumbnails". Then install LO.
I tried the suggestion by Kumara in Comment 11. "In Windows Explorer, go to Organize > Folder and search options > View tab. Tick "Always show icons, never thumbnails". Then install LO." Then I was able to install LO without any problems, and applications so far appear to work properly. So I can recommend this as a possible workaround. Thanks Kumara.
given that bug 56007 is fixed and the shell extensions should be much faster, can anybody still reproduce this problem when upgrading _from_ LO 4.1.4.2 (or later) to a later version?
as per mst's question ...
(In reply to comment #14) > as per mst's question ... /me did not have the bug again (as far as i remember), and i'm currently running 4.2.0.5 on Windows 7 I'm asking others, who can reproduce this, to give info. But i doubt anyone having this problem will be saving enough info in order to post it here when they found this bug.....
I just experienced the same problem, trying to install the 32bits x86 version of LibreOffice (4.2.0.4) on a 32 bits Windows 7 system.
(In reply to comment #11) > Meanwhile, I encourage affected ones to test. In Windows Explorer, go to > Organize > Folder and search options > View tab. Tick "Always show icons, > never thumbnails". Then install LO. This workaround did not help on my system. (In reply to comment #2) > I had to go to task manager and kill > explorer.exe to finish installing. Then, you have to re-launch explorer.exe > to be able to use anything in windows 8.1 . > This did work on my system (32bits windows 7, Intel Pentium Dual Core E5300). When the installer finished, I logged out of windows using task manager and then logged back in to restart explorer and get my desktop back.
I updated from 4.1.4.2 to 4.2.0.4 and the installation worked correctly. In my case the issue seems to be solved. Again this is on Win7 64-bit AMD.
(In reply to comment #16) > I just experienced the same problem, trying to install the 32bits x86 > version of LibreOffice (4.2.0.4) on a 32 bits Windows 7 system. which was the installed LO version _before_ the upgrade?
(In reply to comment #19) > which was the installed LO version _before_ the upgrade? None; in my case it was not an upgrade, but rather a fresh install.
(In reply to comment #20) > (In reply to comment #19) > > which was the installed LO version _before_ the upgrade? > > None; in my case it was not an upgrade, but rather a fresh install. Hmmm... Shall we mark this as major?
(In reply to comment #21) > (In reply to comment #20) > > None; in my case it was not an upgrade, but rather a fresh install. > > Hmmm... Shall we mark this as major? that is the _first_ report of somebody claiming to have this problem on a fresh installation with no older LO installed on the system; since this bug is about upgrades it's probably a different bug which would be UNCONFIRMED, not NEW as this one.
(In reply to comment #22) > that is the _first_ report of somebody claiming to have this problem > on a fresh installation with no older LO installed on the system; > since this bug is about upgrades it's probably a different bug > which would be UNCONFIRMED, not NEW as this one. Please forgive if I'm making a wrong assumption here. It seems to me that it's not a separate bug. The issue is not between the installer program and the installed LO, but between the installer program and Explorer.exe. So, it should make no difference between an upgrade and a fresh install.
I've just upgraded to 4.2.0.4 with Explorer's thumbnails on. No hitches. So, it seems the goal post has moved.
(In reply to comment #23) > (In reply to comment #22) > > that is the _first_ report of somebody claiming to have this problem > > on a fresh installation with no older LO installed on the system; > > since this bug is about upgrades it's probably a different bug > > which would be UNCONFIRMED, not NEW as this one. > > Please forgive if I'm making a wrong assumption here. It seems to me that > it's not a separate bug. The issue is not between the installer program and > the installed LO, but between the installer program and Explorer.exe. So, it > should make no difference between an upgrade and a fresh install. No, _this_ bug is about LO bundled Explorer extensions to view thumbnails of various documents, which somehow prevents installation of new LO versions presumably because these Explorer extension files cannot be overwritten or deleted; naturally on a "fresh" install you won't have LO Explorer extensions running. (actually i cannot imagine how there could be a conflict between Explorer.exe and LO installation without a LO previously installed on the system, but this is Windows and it's full of mysteries so what do i know anyway...)
(In reply to comment #25) > (actually i cannot imagine how there could be a conflict between > Explorer.exe and LO installation without a LO previously installed > on the system, but this is Windows and it's full of mysteries > so what do i know anyway...) Just speculating: I did have MS Office 2013 installed, which also has bindings for open document filetypes. In addition to explorer.exe, the LO installer sometimes also mentioned a Microsoft Office document cache process as one of the things it needed to be terminated before proceeding with the installation. So perhaps Microsoft Office causes a similar connection between explorer and the open document filetypes, and thereby a similar conflict for the LO installer.
*** Bug 78057 has been marked as a duplicate of this bug. ***
Also seem to be having this problem going from 4.2.4.2 to 4.2.5.2. It brings up the error message that files used by this setup need to be closed, Windows Explorer Process ID 5484. Googling that landed me on this questions page http://ask.libreoffice.org/en/question/27733/libreoffice-4142-install-error-files-in-use/ and some further googling to this bug report. I have not tried any of the fixes just in case I can help with identifying the problem but I am, at this stage, wondering if it's related to this issue http://ask.libreoffice.org/en/question/16047/error-1303-when-installing-libreoffice-402-on-windows-8-pro/#30099 which made me install LO in a folder outside the default /Programs folders. I'm on Win 8 (with a Gaelic langpack), 64bit, with Office 2013 also installed.
Dunno if it helps but I just had an odd solution to this problem. I needed to check something in the localization of OO that I also maintain and remembering the issues with having both installed, I uninstalled LO completely before re-installing LO. Now before I installed OO I tried to delete the LO folder under C:/Programs and it would not let me with no specific error message. I then installed OO and had to restart. After re-starting, I could delete the LO folder. Funnily enough I ran into the *same* problem trying to delete the OO folder under C:/Programs before re-start - but again fine AFTER restart. Seems to me like there's some LO process that just keeps on running even after de-installation that interferers with deleting (in my case) or (in the update case) over-writing. At least that's my guess.
The saga continues. There is something ... cavalier about the shoddy install process. So after my last report of being able to install it correctly has to get amended. It installs and fires up and I can open documents from the Recents list but har-dee-har-dee-har, if I use a link on my desktop to open an .odr file or if I browse to it using Explorer, I get this error: "Another program is currently using this file" So I then uninstall LO and re-install it (a chore in itself, the installer is still mental, how about someone sorting the UI languages *alphabetically*???) on my second hard drive in a non-system created folder E:/Programs/ and suddenly everything works again. Seems to me LO does *NOT* like being in the default system folders for programs.
Michael Bauer, thanks for your reports. However, Comment 29 and 30 don't seem to be related to this bug. Please report them elsewhere. I've changed platform too All Windows based on comment 16, and added a comment on whiteboard to a workaround.
I'm not a developer but my gut tells me they ARE related, it's the same chain of installation events the way I see it.
I've not seen this bug for a while. In my last installation, I'm certain that I had thumbnails on. Anyone faced this bug in recent versions?
I've not had it for a few versions either. Perhaps close it for now?
It might be wise to add some info to this bug. Info that shows how to gather some info is needed to solve this bug when someone has this situation again (in a later version) Simply closing because this bug is open for 1 year and 5 month without any progress is a bit odd for developers who want to make a good product. I mean: 'Sorry we cannot reproduce the bug', ...... well lets wait a couple of months, and than put it in a status where no one will ever find it..... ? (I'm aware of the fact that I did not put much info in my bug report, but I don't know how to get more info when this sort of thing happens....)
(In reply to Luuk from comment #35) > It might be wise to add some info to this bug. > Definitely! > Simply closing because this bug is open for 1 year and 5 month without any > progress is a bit odd for developers who want to make a good product. But that's not what people are saying... (In reply to Kumāra from comment #33) > I've not seen this bug for a while. In my last installation, I'm certain > that I had thumbnails on. Anyone faced this bug in recent versions? (In reply to Michael Bauer from comment #34) > I've not had it for a few versions either. Perhaps close it for now? The reason why we spend time on bug reports is so that developers can identify and fix bugs in LibreOffice. If we can't reproduce the problem in a modern version of LibreOffice or on a modern operating system, then a bug report is just a historical record. > > (I'm aware of the fact that I did not put much info in my bug report, but I > don't know how to get more info when this sort of thing happens....) It looks like the last confirmation of this report was a year ago to the day, and in fact the devs are suspicious that said report (comment 16) is even talking about the same bug. It would be great if someone could try to reproduce this problem using a 4.4 or 4.5 build. If we can't reproduce it there, then I think it's most useful for the development workflow for us to mark it as 'RESOLVED WORKSFORME' until someone has the same bug show back up again.
(In reply to Robinson Tryon (qubit) from comment #36) > > It would be great if someone could try to reproduce this problem using a 4.4 > or 4.5 build. If we can't reproduce it there, then I think it's most useful > for the development workflow for us to mark it as 'RESOLVED WORKSFORME' > until someone has the same bug show back up again. Hi Robinson, I upgraded from 4.3 to 4.4.0.3 without problem. Instalation of daily builds 4.5 I'm doing few times in a month and didn't noticed any problem. windows7.
(In reply to Luuk from comment #35) > (I'm aware of the fact that I did not put much info in my bug report, but I > don't know how to get more info when this sort of thing happens....) Have you encountered the same bug in recent versions?
Did encounter this today when tried to upgrade on a win 7 pro 64 Have 4.2.8.2 and was trying to install 4.3.6
According to collective wisdom of people on internet, it is not possible to unload a shell extension dll during uninstall. If the file is in use, then restart is needed.
*** Bug 95435 has been marked as a duplicate of this bug. ***
(In reply to Beluga from comment #41) > *** Bug 95435 has been marked as a duplicate of this bug. *** So looks like the problem remains. So, I'm reopening it.
Closing per comment 40. Do not reopen again. Marking another bug as a duplicate does not automatically accounts to changing the other bug’s resolution.
*** Bug 93158 has been marked as a duplicate of this bug. ***
I don't doubt the collective wisdom of the internet but restarting the system does not fix the issue. I have tried restarting the system umpteen times when I get a LO release with this problem.
(In reply to Adolfo Jayme from comment #43) > Closing per comment 40. Do not reopen again. Marking another bug as a > duplicate does not automatically accounts to changing the other bug’s > resolution. True, but the bug remains, and I can imagine any less-than-tech-savvy user to be put off by it. If this is impossible to fix technically, at the very least, give the user the heads-up in the Windows installation dialog. I'm not sure which is better: 1. Terminate Explorer, Continue with LO installation, Restart Explorer 2. As I suggested in Comment 11.
There is a third option. Create a directory OUTSIDE ../Programs or ../Programs (x86) (whatever the Windows default is the system in question. For some odd reason, that workaround always works. We could add a message saying "Windows is preventing LO from installing to this directory. Would you like us to create c:\LO (or whatever) and continue with the installation?"
Migrating Whiteboard tags to Keywords: (notBibisectable) [NinjaEdit]
Just tried to install 5.1.2 and got this one again. I'm re-opening the bug in spite of what Adolfo said. With all due respect, it is *crazy* to leave a bug unresolved (however ugly the solution might be). It's a bug that prevents installation of the product to a not insignificant number of people. If that's not shooting ourselves in the foot, the I don't know what is. At the *very* least the error message needs modified to give the user a clue as to what's going on and how to work around it.
Can not reproduce. On Windows 10 Pro 64-bit en-US with Version: 5.2.0.3 (x64) Build ID: 7dbd85f5a18cfeaf6801c594fc43a5edadc2df0c CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Locale: en-US (en_US) Upgraded install to Version: 5.2.0.4 (x64) Build ID: 066b007f5ebcc236395c7d282ba488bca6720265 CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Locale: en-US (en_US) 1. Windows Explorer open and view mode set to Large Icons 2. Windows Explorer Options -> Change folder and Search options -> Folder Options dialog -> View tab "alwasy show icons, never thumbnails" set *unchecked* -- ODF thumbnails are displayed. 3. opened Command Prompt (Admin) so "Run as Administrator" 4. CLI upgrade with verbose logging "msiexec.exe /i LibreOffice_5.2.0.4_Win_x64.msi /L*v upgradeInstall5204.log" 5. during the upgrade use Windows Explorer and change between folders with ODF documents. Documents continue to show thumbnails--but briefly show only ODF icons--then back to thumbnails. 6. upgrade runs to completion Review of the log reveals nothing had blocked for any of the "shlxthdl" DLLs: ooofilt.dll, shlxthdl.dll, propertyhdl.dll The ops to remove and then install and then register all seem normal.
Came across this after a mention in IRC. I've some substantial experience as a system administrator in an company that uses Windows desktops. I had countless installs/upgrades/uninstalls of MSIs and non-MSI installer. And I must say that there is only **one** comment here that marks some possible problem. That's comment 2, that says that > If you tell it to ignore it, it will not proceed until you close it. > I had to go to task manager and kill explorer.exe to finish installing That's really strange. Otherwise, the MSI-based installer telling you that Explorer.exe is using a resource, and should be closed to avoid restart, is perfectly OK. MSI technology in made to do that. And it's OK for explorer.exe to use LO shell extension DLL - and there's no way to unload it other than close explorer.exe. Normal sequence is this: installer detects a busy resource; it tries to find a process that holds it busy; (some installers also look for windows with some pre-defined strings, thus firing false positives); if it finds one, it asks to close it, and warns that otherwise a reboot required. If user agrees to close it, the process closes and install continues normally, replacing the previously-busy DLL. If user disagrees, then the new DLL is copied to a temporary place to be replaced at reboot; and after the installation finishes, it asks for reboot. The problems that are discussed here must be as follows: (1) if the installer is UNABLE to continue without closing explorer.exe; and (2) if it is UNABLE to close explorer.exe when told so. If these two cases do happen, then they should really must be debugged and fixed. Otherwise, if the described normal behaviour takes place, then it is not anyone's bug.
(In reply to Mike Kaganski from comment #51) > Normal sequence is this: > installer detects a busy resource; it tries to find a process that holds it > busy; (some installers also look for windows with some pre-defined strings, > thus firing false positives); if it finds one, it asks to close it, and > warns that otherwise a reboot required. If user agrees to close it, the > process closes and install continues normally, replacing the previously-busy > DLL. > If user disagrees, then the new DLL is copied to a temporary place to be > replaced at reboot; and after the installation finishes, it asks for reboot. I agree, except that many other installers attempt to restart explorer.exe at the end of the installation process. For example, the installers of cloud/encryption services like SpiderOak or BoxCryptor, which also need to close explorer during installation, do exactly that. If there are still scenarios in which the current LibreOffice version's installer needs to close explorer.exe, than that would be a welcome functionality for non-tech savvy users, as many of them do not know how to start explorer.exe manually when their task bar and start menu have disappeared.
MSIRESTARTMANAGERCONTROL https://msdn.microsoft.com/en-us/library/windows/desktop/aa370377
Taking
Summary: The goal is to allow installer to automatically close and restart closed applications, and thus diminish users frustration when they don't know how to close explorer.exe, or how to start it again and bring desktop back. Reference: https://msdn.microsoft.com/en-us/library/windows/desktop/aa370379 Notes: * The feature is called Restart Manager. * A dialog MsiRMFilesInUse must be present in MSI. * It will only be used when operating system's Windows Installer version is >=4.0, and OS is Vista or newer. If system's Windows Installer is older, then current FilesInUse dialog will be used. * MSIRESTARTMANAGERCONTROL property, that is not defined in LO MSI, has default value of 0, that enables installer to use the restart manager. A patch is submitted to gerrit for review: https://gerrit.libreoffice.org/28171
Created attachment 126859 [details] New RestartManager installation dialog The patch from gerrit produces this.
I must notice that the Restart Manager isn't particularly reliable anyway. I see reports that it often cannot close some processes here and there for unknown reasons; that it fails to restart them (specifically, explorer.exe) on some occasions; that sometimes after choosing "do not close and restart", it brings that old notice from attachment 85393 [details], etc. As Michael Stahl said, that's Windows... I expect that to be a new source of "bug" reports. What are other options (not necessarily mutually exclusive): 1. We can totally hide the dialogs and always reboot at the "resource busy" event. Some sources suggest that hiding the dialogs allows that. But that's not the MS-recommended way, it's against "MS-Logo" guidelenes if that matter, and it surely will make bad LO install process reputation for requirement to always reboot when it could be avoided. 2. If someone finds a way to unload the LO DLLs, (e.g. by using some interprocess communication that is established by those DLLs to request their unloading), then we may use a custom event to do that to make "resource busy" event less often - but that's not a good idea, because it will be error-prone, use more system resources, and may cause security issues.
Merged that effort to master (5-3) as https://cgit.freedesktop.org/libreoffice/core/commit/?id=190f0685c866b6232564c9d207456d3292d7a551 Lets give qa a while to test the install over the next week or so and if all goes well consider backporting to 5-2. Call this closed for now and if there are still lingering problems with the new approach open new bugs to deal with them as best we can, because this is now an unmanageable sprawling 50+ comment bug.
*** Bug 104585 has been marked as a duplicate of this bug. ***
(In reply to Mike Kaganski from comment #59) > *** Bug 104585 has been marked as a duplicate of this bug. *** I can empathise with the new bug reporter. I recently experienced this bug again too, while upgrading to 5.2.3.3.
Just to sort things up: That installer wants to close <any app here, including explorer.exe> *is not a bug*. If that program has locked a resource that installer needs to replace, it is obvious that is must stop doing so, otherwise a reboot will be necessary. A program may lock a file by, e.g., opening it (say, you may open an editor to see LO license), or by using LO DLLs. These DLLs are there to allow e.g. explorer to show previews, and it is OK for programs to do that. But when a program have started using it, it's only that program that can decide when to release the DLL. If it doesn't do that, then we cannot force unloading the DLL, or bad things may happen when suddenly the program decides to continue using a data/function from the DLL that had been forcefully unloaded. So, there's nothing to be done with the fact that LO asks (and will always ask) to unload programs, *including explorer*, in case when Windows tells the installer that those programs use necessary resources. End of story.
There's always something that can be done. For instance, the problem only seems to occur when LO tries to install itself in one of Windows' default "Programs" folders. If I could code, I'd out in a step which makes LO, when it wants to flash this error at the user, install itself in C:\LibreOffice instead, problem solved for the end user... Or just install it in C:\LibreOffice for everyone and be done with this lunacy.
Cannot install LibreOffice_5.2.5_Win_x86 due to this issue. My System: Windows 10 Home, 64 bit, German
(In reply to Tobias Heilig from comment #63) As mentioned in keywords, the fix is targeted to version 5.3.0. Comment 58 proposed to backport it to 5-2, but that hasn't happened. Please don't reopen the bug unless you see the problem in a version where the bug is considered fixed.
Wrt "regression" part: http://mail-archives.apache.org/mod_mbox/openoffice-dev/201702.mbox/%3CDB3PR05MB0826B900EE0A71E0E7163C00E84E0%40DB3PR05MB0826.eurprd05.prod.outlook.com%3E