Bug 149106 - LOdev 7.4.0.0alpha1 cannot be installed over an existing installation
Summary: LOdev 7.4.0.0alpha1 cannot be installed over an existing installation
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
7.4.0.0 alpha0+
Hardware: x86-64 (AMD64) Windows (All)
: highest critical
Assignee: Samuel Mehrbrodt (allotropia)
URL: https://docs.microsoft.com/en-us/trou...
Whiteboard: target:7.4.0
Keywords: bisected, regression
Depends on:
Blocks:
 
Reported: 2022-05-16 09:47 UTC by Stefan_Lange_KA@T-Online.de
Modified: 2022-06-12 21:49 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Screenshot of the aborted/interrupted installation (70.98 KB, image/png)
2022-05-16 09:47 UTC, Stefan_Lange_KA@T-Online.de
Details
Log file from aborted installation (3.04 MB, application/octet-stream)
2022-05-16 13:07 UTC, Stefan_Lange_KA@T-Online.de
Details
zipped content of folder c:\Program Files\LibreOfficeDev 7\ (134.23 KB, application/x-zip-compressed)
2022-05-17 14:52 UTC, Stefan_Lange_KA@T-Online.de
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan_Lange_KA@T-Online.de 2022-05-16 09:47:02 UTC
Created attachment 180134 [details]
Screenshot of the aborted/interrupted installation

Starting with LibreOfficeDev_7.4.0.0.alpha1_Win_x64.msi I cannot install a new LOdev build over an installed older LOdev version (e.g. over LOdev 7.3.4, LOdev 7.4.0.0.alpha0).
The installation starts as usual but after the request for permission (e.g. authorize as administrtor) it is aborted as if the question was answered with "No", s. attached screenshot (in german)!
To install the builds of LOdev 7.4.0.0.alpha1 I must first uninstall the existing LOdev version. 

Until the last build of LibreOfficeDev_7.4.0.0.alpha0_Win_x64.msi (from folder /daily/master/Win-x86_64@tb77-TDF/2022-05-12_05.15.51/) the installation over an existing version was possible commonly without problems.
I don't know if this is a bug or if the new behavior is by design.
Comment 1 sdc.blanco 2022-05-16 09:56:49 UTC
Repro.  And actually -- starting slightly before LibreOfficeDev_7.4.0.0.alpha1_Win_x64.msi.

I could install on top of existing LibreOfficeDev_7.4.0.0.alpha0+:

https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/2022-05-09_05.07.31/

Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: cdf8e971d5d46df4bcab35a99c4254df9459213f
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: da-DK (da_DK); UI: en-US
Calc: CL

but not from:

https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/2022-05-12_05.15.51/

and onward.

(did not try with https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/2022-05-11_05.43.59/ )

Did not try to uninstall and re-install.
Comment 2 Mike Kaganski 2022-05-16 10:41:23 UTC
Please create an installation log, as described in the FAQ:

https://wiki.documentfoundation.org/Faq/General/General_Installation_Issues_(Windows)#Create_an_installation_log
Comment 3 Stefan_Lange_KA@T-Online.de 2022-05-16 12:01:18 UTC
(In reply to sdc.blanco from comment #1)
> Repro.  And actually -- starting slightly before
> LibreOfficeDev_7.4.0.0.alpha1_Win_x64.msi.
> 
> I could install on top of existing LibreOfficeDev_7.4.0.0.alpha0+:
> 
> https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/2022-05-
> 09_05.07.31/
> 
> Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
> Build ID: cdf8e971d5d46df4bcab35a99c4254df9459213f
> CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL:
> win
> Locale: da-DK (da_DK); UI: en-US
> Calc: CL
> 
> but not from:
> 
> https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/2022-05-
> 12_05.15.51/
> 
> and onward.
> 
> (did not try with
> https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/2022-05-
> 11_05.43.59/ )
> 
> Did not try to uninstall and re-install.

You are right: The last build installable over an other version was this from /daily/master/Win-x86_64@tb77-TDF/2022-05-11_05.43.59/. The build from /daily/master/Win-x86_64@tb77-TDF/2022-05-12_05.15.51/ is the first not installable over.
Comment 4 Stefan_Lange_KA@T-Online.de 2022-05-16 13:07:57 UTC
Created attachment 180136 [details]
Log file from aborted installation
Comment 5 Timur 2022-05-16 14:11:30 UTC
I confirm, tested in W10.
Comment 6 Mike Kaganski 2022-05-16 14:59:58 UTC Comment hidden (obsolete)
Comment 7 Mike Kaganski 2022-05-16 15:05:53 UTC
Regression after commit 86453991a7ca0c7f90ae95769ee23cd5ccecd83f

  Author Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
  Date   Wed May 11 11:20:30 2022 +0200
    Add error handling to RenamePrgFolder and RemovePrgFolder
Comment 8 Stefan_Lange_KA@T-Online.de 2022-05-16 15:18:50 UTC
(In reply to Mike Kaganski from comment #6)
> (In reply to sdc.blanco from comment #1)
> > but not from:
> > 
> > https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/2022-05-
> > 12_05.15.51/
> 
> Could you please provide the build id of that build? The full Help->About is
> just a must for every mention of a version, the reference to download
> location is not a replacement ;)

build folder: /daily/master/Win-x86_64@tb77-TDF/2022-05-12_05.15.51/

Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: fe687d1b8f5305edfb167152a4fb19ffa20c5404
CPU threads: 4; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: threaded
build folder: /daily/master/Win-x86_64@tb77-TDF/2022-05-12_05.15.51/
Comment 9 Samuel Mehrbrodt (allotropia) 2022-05-17 14:10:47 UTC
Can you tell me what is in your "C:\Program Files\LibreOfficeDev 7\" folder?
Comment 10 Stefan_Lange_KA@T-Online.de 2022-05-17 14:27:14 UTC
(In reply to Samuel Mehrbrodt (allotropia) from comment #9)
> Can you tell me what is in your "C:\Program Files\LibreOfficeDev 7\" folder?

This is the folder where the old LOdev version is installed [except I have uninstalled before] and where the new version should be installed.
IMHO this is the default installation folder for LOdev on Windows systems.
Comment 11 Samuel Mehrbrodt (allotropia) 2022-05-17 14:31:29 UTC
(In reply to Stefan_Lange_KA@T-Online.de from comment #10)
> (In reply to Samuel Mehrbrodt (allotropia) from comment #9)
> > Can you tell me what is in your "C:\Program Files\LibreOfficeDev 7\" folder?
> 
> This is the folder where the old LOdev version is installed [except I have
> uninstalled before] and where the new version should be installed.
> IMHO this is the default installation folder for LOdev on Windows systems.

Yes, can you please show me the content of that directory?
Comment 12 Timur 2022-05-17 14:32:43 UTC
I have the LO folders in C:\Program Files\LibreOfficeDev 7\ from 7.4+, which I didn't uninstall manually.
Same folders as in C:\Program Files\LibreOffice\ from 7.2: help, presets, program, readmes, share and files.
Comment 13 Mike Kaganski 2022-05-17 14:47:02 UTC
(In reply to Samuel Mehrbrodt (allotropia) from comment #11)

RenamePrgFolder seems to be an immediate-execution DLL custom action. That means that it would run with user credentials (not scheduled for deferred elevated execution), and thus it would fail unconditionally when attempted to rename anything in Program Files (where normal user doesn't have writable permissions).

Another failure (even if the action were ) could be when the renamed directory is being used; the normal MSI behavior in that case would be to have the new files copied to a temporary directory, and schedule a reboot to update the now-used files. But the action in question seems to try to do manually what should be done automatically.

I seem to remember some discussion about the action(s); possibly we decided then that it makes sense to keep that for now - I don't remember; but returning the error from the action looks problematic.
Comment 14 Stefan_Lange_KA@T-Online.de 2022-05-17 14:52:35 UTC
Created attachment 180164 [details]
zipped content of folder c:\Program Files\LibreOfficeDev 7\
Comment 15 Samuel Mehrbrodt (allotropia) 2022-05-17 14:59:53 UTC
(In reply to Mike Kaganski from comment #13)
> (In reply to Samuel Mehrbrodt (allotropia) from comment #11)
> 
> RenamePrgFolder seems to be an immediate-execution DLL custom action. That
> means that it would run with user credentials (not scheduled for deferred
> elevated execution), and thus it would fail unconditionally when attempted
> to rename anything in Program Files (where normal user doesn't have writable
> permissions).

Ah that makes sense. It worked fine for me when I tested this.

> Another failure (even if the action were ) could be when the renamed
> directory is being used; the normal MSI behavior in that case would be to
> have the new files copied to a temporary directory, and schedule a reboot to
> update the now-used files. But the action in question seems to try to do
> manually what should be done automatically.

Any hints how that can be implemented (having files updated after reboot)?

> I seem to remember some discussion about the action(s); possibly we decided
> then that it makes sense to keep that for now - I don't remember; but
> returning the error from the action looks problematic.

Yep, when testing it looked to me that returning an error did not abort the installation, but just wrote something in the log file. Not sure why this user sees a different behavior.
Comment 16 Stefan_Lange_KA@T-Online.de 2022-05-17 15:07:17 UTC
(In reply to Samuel Mehrbrodt (allotropia) from comment #11)
> (In reply to Stefan_Lange_KA@T-Online.de from comment #10)
> > (In reply to Samuel Mehrbrodt (allotropia) from comment #9)
> > > Can you tell me what is in your "C:\Program Files\LibreOfficeDev 7\" folder?
> > 
> > This is the folder where the old LOdev version is installed [except I have
> > uninstalled before] and where the new version should be installed.
> > IMHO this is the default installation folder for LOdev on Windows systems.
> 
> Yes, can you please show me the content of that directory?

I have attached the zipped dir output of the folder "c:\Program Files\LibreOfficeDev 7\".

Currently there is installed LOdev 7.3.4.0.0+ (x64) / LibreOffice Community Build ID: 54f0c89ef7a93b12e6be67716bc55a47b69cb9a6 (recent LOdev 7.3.4 build from today).
Before creating the dir output I have once more started the installation of LOdev, this time for 7.4.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 817b8fe7001a83cb74910eb09b7c14a3b95b8a39 - as expected without succes.

I hope the dir output helps.
Comment 17 Mike Kaganski 2022-05-17 15:23:29 UTC
(In reply to Samuel Mehrbrodt (allotropia) from comment #15)
> (In reply to Mike Kaganski from comment #13)
> > (In reply to Samuel Mehrbrodt (allotropia) from comment #11)
> > 
> > RenamePrgFolder seems to be an immediate-execution DLL custom action. That
> > means that it would run with user credentials (not scheduled for deferred
> > elevated execution), and thus it would fail unconditionally when attempted
> > to rename anything in Program Files (where normal user doesn't have writable
> > permissions).
> 
> Ah that makes sense. It worked fine for me when I tested this.

Could it be that you have e.g. UAC disabled? That would allow logged in admin to avoid all the "do you want to allow the program ...?" questions, but at the same time, would hide the error - because the user credentials would allow the rename.

> > Another failure (even if the action were ) could be when the renamed
> > directory is being used; the normal MSI behavior in that case would be to
> > have the new files copied to a temporary directory, and schedule a reboot to
> > update the now-used files. But the action in question seems to try to do
> > manually what should be done automatically.
> 
> Any hints how that can be implemented (having files updated after reboot)?

That does not require anything at all: it's how MSI works normally. I always was confused why OOo (and now LO) needed the custom actions at all ... The custom actions seem to try to duplicate the normal MSI functionality - and might themselves be a reason of some failures IMO.
Comment 18 Mark 2022-05-17 22:17:50 UTC
The device that 7.4 Alpha installation fails on had a prior LibreOffice 7 folder for the dev version of 7.3.x

After deleting that folder and rebooting the device, the 7.4 Alpha install still fails.

The device on which the 7.4 installation completes successfully has a LibreOffice 7 folder which launches 7.4 Alpha. I do not recall whether this device had a previous dev version installed.
Comment 19 kabilo 2022-05-18 09:14:09 UTC
I confirm, tested in W8.1 (LibreOfficeDev_7.4.0.0.alpha1_Win_x64.msi from 2022-May-18 02:59)
Comment 20 Samuel Mehrbrodt (allotropia) 2022-05-18 09:20:57 UTC
(In reply to Mike Kaganski from comment #17)
> > > Another failure (even if the action were ) could be when the renamed
> > > directory is being used; the normal MSI behavior in that case would be to
> > > have the new files copied to a temporary directory, and schedule a reboot to
> > > update the now-used files. But the action in question seems to try to do
> > > manually what should be done automatically.
> > 
> > Any hints how that can be implemented (having files updated after reboot)?
> 
> That does not require anything at all: it's how MSI works normally. I always
> was confused why OOo (and now LO) needed the custom actions at all ... The
> custom actions seem to try to duplicate the normal MSI functionality - and
> might themselves be a reason of some failures IMO.

So, let's try to remove these actions completely then: https://gerrit.libreoffice.org/c/core/+/134513
Comment 21 Commit Notification 2022-05-18 20:51:47 UTC
Samuel Mehrbrodt committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/955fd1c534c061b3b6992dfe034b62b46ee2e844

tdf#149106 Remove RenamePrgFolder and RemovePrgFolder custom msi actions

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 22 Thorsten Behrens (allotropia) 2022-05-18 22:28:25 UTC
Assuming this is fixed now, could affected people please check with the next nightly build tomorrow?
Comment 23 Stefan_Lange_KA@T-Online.de 2022-05-19 07:15:42 UTC
For me it looks good:
I have installed 
Version: 7.4.0.0.alpha1+ (x64) / LibreOffice Community
Build ID: a353f633ec029fc5c7cdc8062aefb6f979265a9e
CPU threads: 4; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: threaded
on top of the existing version of LOdev 7.4.

Many thanks for resolving the bug!
Comment 24 sdc.blanco 2022-05-21 08:05:42 UTC
(In reply to Mike Kaganski from comment #6)
> (In reply to sdc.blanco from comment #1)
> > but not from:
> > 
> > https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/2022-05-
> > 12_05.15.51/
> 
> Could you please provide the build id of that build? The full Help->About is
> just a must for every mention of a version, the reference to download
> location is not a replacement ;)
I was able to install from:

https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/2022-05-20_05.07.28/

aka: Build ID: 09822cf77cdbe32b03553cd05154100b5f2591d0   (-:

Thanks Samuel and Mike for a solution.

fwiw -- I checked the Properties of the build that I could not install -- exactly to see if there was a build id. (There wasn't.)

Maybe there is an easy way to automatically add that information to "Description".  Would make it easier to report "impossible" information. ;)