Description: Why is a user still forced to restart the whole computer efter installation of LibreOffice, eg v24.2.3.2, due to the fact that the inferior installation routine of LibreOffice can not cope with a running File Explorer? It is extremely cumbersome and annoying to have to reboot a computer just for this reason. Actual Results: N. Expected Results: No Reproducible: Always User Profile Reset: Yes Additional Info: No
Nothing can be done, when LibreOffice needs to replace its components (including e.g. Windows shell extension), and Windows Explorer has them open.
An why is that? No other application forces a restart of Windows. Is there a bad design choice somewhere in the handling of the LibreOffice installation...?
I see that this question has been raised many times, and that the "answers" given are not to any satisfaction...
(In reply to Lars.H.Nilsson from comment #2) > No other application forces a restart of Windows. This is wrong. Just you happen to not come across that.
You're not, just the DE of the Windows shell needs to restart. Task Manager --> Details tab --> locate "explorer.exe" --> context menu 'End task' Just the Task Manager will continue to run. From its File --> 'Run new task' --> type "explorer.exe" Will relaunch the desktop environment with updated versions as needed. There are some instances, don't think there are any in the LibreOffice installs, when a full restart is still required. But, this is correctly => NAB
Can then this be adjusted for future LibreOffice releases, so that the installation scripts themself take care of this procedure, without presenting the overly dramatic "need to reboot the computer" information to the user, if there indeed are no technical requirements for a real reboot?
We do not use "installation scripts". We use Microsoft technology named "Windows Installer", which takes a list of files and registry values, and does everything that is needed to put them to the destination. When Windows Installer thinks that a reboot is needed, it tells you so. There is no plans to change the installation technology.
(In reply to Lars.H.Nilsson from comment #6) > Can then this be adjusted for future LibreOffice releases, so that the > installation scripts themself take care of this procedure, without > presenting the overly dramatic "need to reboot the computer" information to > the user, if there indeed are no technical requirements for a real reboot? As for bug 69066 (read from about cmnt 51), we already make use of the Windows installer provided "Restart Manager" that is intended to perform this task, but it has warts. As noted it may be possible, but not a priority, to modify the LibreOffice installer with custom actions to halt/unload any in use LO libraries to avoid the "resource in use" errors that trigger the restart manager dialogs. For now the dialog *as implemented* is the best option for reliable installations.
(In reply to V Stuart Foote from comment #8) > As noted it may be possible, but not a priority, to modify the LibreOffice > installer with custom actions to halt/unload any in use LO libraries to > avoid the "resource in use" errors that trigger the restart manager dialogs. I'm unsure what you refer to. The Restart Manager is *intended* to do exactly that: in case when the system sees that a file is locked by a process, it tries to unload that process. If the system component fails that, there is no way LibreOffice would do something bigger to halt random processes.
(In reply to Mike Kaganski from comment #9) It was you who'd suggested a route in https://bugs.documentfoundation.org/show_bug.cgi?id=69066#c57 where to avoid the nuisance explorer.exe shell restart (or the Restart Managers dialog) we would have to implement some internal signaling to processes (I would expect for just a few troublesome DLL) needing to be shutdown for update. Mutex and WM_QUERYENDSESSION aware. Of course you did decide to implement the basic MsiRMFilesInUse control in the installer. Expect we'd have to manage something internally to LO to be triggered by custom actions (in the UI sequence table) for the installer, and so could by-pass the Windows Installer's Restart Manager handling for specific dll. As in this thread [1] and similar , with its linked Windows Installer "Custom Action Execution Scheduling Options" [2] But seems like the Restart Manager does provide options in "RegisterApplicationRestart" RmRegisterResources for specific DLLs (parsed as RM_PROCESS_INFO / RM_UNIQUE_PROCESS and adding a MSIRMSHUTDOWN=2 value) to force a process to stop. Though going the installer custom action route might still be needed for anything causing issues. [3] Not saying we should, or that it is merited to by-pass "normal" Windows installer handling (with the Restart Manager in control), or that it would be worth the dev-effort. Just that it was possible. Also, with some effort going to bring in a WIX packager, might be some additional alternatives there. NTL this is still => NAB =-ref-= [1] https://stackoverflow.com/questions/2721093/windows-installer-custom-action-before-any-validation [2] https://learn.microsoft.com/en-us/windows/win32/msi/custom-action-execution-scheduling-options?redirectedfrom=MSDN [3] https://stackoverflow.com/questions/50917062/windows-installer-avoid-fileinuse-dialog-box-when-installing-a-package
(In reply to V Stuart Foote from comment #10) > (In reply to Mike Kaganski from comment #9) > It was you who'd suggested a route in > https://bugs.documentfoundation.org/show_bug.cgi?id=69066#c57 Nice find - I confess that I missed that my bug 69066 comment 57, and totally forgot that I already explained that the implemented mechanism is not particularly reliable. I agree with your analysis. I can only say, that with some additional experience gathered over these years, I know for sure, that there is no safe way to unload a DLL from a process that loaded it, without shutting down the whole process (so my point 2 there was just a wishful thinking). And that shutting down the processes is already attempted in a OS-endorsed way, with the change I introduced there.