[Libreoffice-bugs] [Bug 134103] Windows Installer MSI package can not install if \Windows\Installer path is a junction point or symbolic link to another folder location

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=134103

Mike Kaganski <mikekaganski at hotmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |NOTOURBUG

--- Comment #4 from Mike Kaganski <mikekaganski at hotmail.com> ---
Thank you very much for this extensive testing!

(In reply to João Paulo from comment #3)
> After these testings, I suspect with you that it is not a bug on LibreOffice
> side (there are, though, some .msi packages that don't accept
> \Windows\Installer being a symbolic link to another folder), but some update
> to Windows 10 that broke Windows Installers.  There is an easy workaround
> that is erasing any Config.Msi folders on the system, be them located at the
> root of the lettered volumes ([C|D|E|F|G|...]:\Config.Msi) or at
> C:\Windows\Installer.

I close it then as NOTOURBUG.

> However, as not all users that download and install LibreOffice knows how to
> fix it, until Microsoft does not fix this bug (I will send them these
> findings), I suggest considering to create a custom action into LibreOffice
> MSI package to delete %SYSTEMDRIVE%\Config.Msi and
> %SYSTEMROOT%\Installer\Config.Msi before and after doing any actual
> installation steps.  What do you think?

I don't think we can do that. The directories may contain information still
used by Windows Installer: either from including nested MSIs (a deprecated, but
yet existing feature if MSI), or from installation already finished, but
waiting for reboot (or even it could affect our installation: these directories
are managed by Windows Installer; and I don't have enough knowledge that any
existing or *future* version of the service dos not use the directories prior
to run the custom action for some technical reason). Removal of that
information could harm those installations, and put the system into
inconsistent state to the extent of requiring to repair/reinstall OS. So no, we
can't consider that workaround.

However, the scenario you describe is not something any user is likely to
encounter: we are dealing with redirecting system paths - and you know, it's up
to advanced users to do that. I suppose that if you post a blogpost with your
findings and the workaround (so that users know that they are not running an
installation, and no installation is pending a reboot, and are safe to remove
the directories outside of these conditions), it would be a reasonable means to
workaround. Possibly even publishing this thing on our FAQ page [1] as a thing
to try in case of general failure.

[1]
https://wiki.documentfoundation.org/Faq/General/General_Installation_Issues_(Windows)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200628/faba92e1/attachment-0001.htm>