Bug 123012 - Upgrade can fail with running LO processes
Summary: Upgrade can fail with running LO processes
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
(earliest affected) Master
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
Depends on:
Reported: 2019-01-28 10:45 UTC by Gabor Kelemen
Modified: 2019-01-28 12:13 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

Upgrade of types.rdb failed (28.96 KB, image/png)
2019-01-28 10:45 UTC, Gabor Kelemen
Upgrade with install dir change can cause crash (79.06 KB, image/png)
2019-01-28 10:46 UTC, Gabor Kelemen
Upgrade can mark some files for later replacement, but not every single one (156.30 KB, image/png)
2019-01-28 10:46 UTC, Gabor Kelemen

Note You need to log in before you can comment on or make changes to this bug.
Description Gabor Kelemen 2019-01-28 10:45:23 UTC
Created attachment 148704 [details]
Upgrade of types.rdb failed

These are two somewhat rare situations that randomly plague our user base.

* When we centrally trigger the upgrade process on Windows 7 via SCCM, and users are running LO at the same time, the upgrade sometimes - but not always; we are yet unsure exactly how to trigger this behavior - fails and leaves an inoperable installation behind.

The error message is on the types-rdb-54.png picture, sent by one of our users. Some .rdb files fail to correctly upgrade and then LO no longer starts, only a reinstall helps.

* Another issue is on the second picture (LO5-6.PNG), taken while testing a 5.4 -> 6.0 upgrade in the test environment while LO was running. Because the default install directory changed to be versionless, the upgrade run smoothly, but left the running process with removed libraries to a swift crash. This can be called sort of a bad user experience.

We think these two issues have a common root, that is the lack of proper detection of a running instance and subsequently marking every new file - not only a select few (shown on LO607-install.PNG) - for delayed installation.
Comment 1 Gabor Kelemen 2019-01-28 10:46:01 UTC
Created attachment 148705 [details]
Upgrade with install dir change can cause crash
Comment 2 Gabor Kelemen 2019-01-28 10:46:56 UTC
Created attachment 148706 [details]
Upgrade can mark some files for later replacement, but not every single one
Comment 3 Mike Kaganski 2019-01-28 10:57:43 UTC
LibreOffice MSI installer itself does not has a custom logic to detect running instances; that isn't a subject for custom logic actually, but is a function of Windows Installer service, which has the MSI database for reference which files must be removed/replaced, and if they are currently in use by some process. If it cannot replace them, it may offer a dialog to user (in UI mode), and delay-install the locked files.

In any case, if only some of files are being used by a process, those files only would be delay-installed; others would be removed/replaced, which of course would mean a crash opportunity for a running process which suddenly decided to access a file which was removed (by the way, even if there were not directory change, such an operation can give crashes, because replaced (i.e., existing) newer files could happen to be incompatible with running older executable).

Of course, I agree with you that an IT department doing such replacements while users work creates sort of bad user experience ...
Comment 4 Timur 2019-01-28 12:13:52 UTC
I also observed the issue with "types.rdb: no such File" on some Windows 7 computers during centralized upgrade LO 5.3 -> LO 
I didn't see it myself before 5.4 although there was something for LO 5.1 on ASK. Similar at https://ask.libreoffice.org/en/question/138028/libreoffice-54-fatal-error/.
I confirm that reinstall was needed, profile reset didn't help.