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.
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.
Please create an installation log, as described in the FAQ: https://wiki.documentfoundation.org/Faq/General/General_Installation_Issues_(Windows)#Create_an_installation_log
(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.
Created attachment 180136 [details] Log file from aborted installation
I confirm, tested in W10.
(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 ;)
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
(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/
Can you tell me what is in your "C:\Program Files\LibreOfficeDev 7\" folder?
(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.
(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 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.
(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.
Created attachment 180164 [details] zipped content of folder c:\Program Files\LibreOfficeDev 7\
(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.
(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.
(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.
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.
I confirm, tested in W8.1 (LibreOfficeDev_7.4.0.0.alpha1_Win_x64.msi from 2022-May-18 02:59)
(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
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.
Assuming this is fixed now, could affected people please check with the next nightly build tomorrow?
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!
(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. ;)