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.
Created attachment 148705 [details]
Upgrade with install dir change can cause crash
Created attachment 148706 [details]
Upgrade can mark some files for later replacement, but not every single one
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 ...
I also observed the issue with "types.rdb: no such File" on some Windows 7 computers during centralized upgrade LO 5.3 -> LO 184.108.40.206.
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.