[Libreoffice-bugs] [Bug 94216] Unable to Install x86 5.0.1.2 on x86-64 W10: Error 1303
bugzilla-daemon at bugs.documentfoundation.org
bugzilla-daemon at bugs.documentfoundation.org
Tue Apr 23 09:25:43 UTC 2019
https://bugs.documentfoundation.org/show_bug.cgi?id=94216
--- Comment #33 from Mike Kaganski <mikekaganski at hotmail.com> ---
Some notes:
(In reply to V Stuart Foote from comment #8)
> at line 89002 things go sideways--- set target is fine, but source folder
> gets boinked. "Folder=1\program\" with a ChangeMedia call to mount it.
>
> That is odd.
>
> =-=-=
>
>
> Action 13:14:19: InstallFiles. Copying new files
> MSI (s) (98:48) [13:14:19:593]: Executing op:
> ProgressTotal(Total=560334165,Type=0,ByteEquivalent=1)
> MSI (s) (98:48) [13:14:19:593]: Executing op:
> SetTargetFolder(Folder=C:\Program Files (x86)\LibreOffice 5\program\)
> MSI (s) (98:48) [13:14:19:593]: Executing op:
> SetSourceFolder(Folder=1\program\)
> MSI (s) (98:48) [13:14:19:593]: Executing op:
> ChangeMedia(MediaVolumeLabel=DISK1,MediaPrompt=Please insert the disk:
> 1,MediaCabinet=libreoffice1.cab,BytesPerTick=65536,CopierType=2,
No that's OK. The command selects *first MSI cabinet* and "program" directory
in it as the source of files. Regarding a question from comment 9 wrt "why is
it looking for C:\Windows\Installer\... for the source location?" - well,
Windows Installer saves a copy of installation database to its own folder for
deferred (run with elevated privileges) phase. That's normal, too.
(In reply to Dirk Munk from comment #19 and comment #20)
These are the two really good comments. The problem here is that updating
LibreOffice first *uninstalls* previous version (it asks Windows Installer to
do its normal job removing an installed package) - and in that process,
LibreOffice directory under Program Files is removed. But - yes, *sometimes*,
for unclear reasons directly related to used state of the directory, it might
hang in a "limbo state", not being removed completely. That might have
something to do with multitude of Windows locking/sharing mode combinations,
when a process might open a directory with a permission that others processes
are free to delete the directory - but then Windows mush still guarantee
somehow that the directory handle owned by first process is still valid... but
that is completely out of control of LibreOffice installation database.
What is relevant is that the problem could likely be solved only by avoiding
removing older version prior to installation of the newer version (moving
installer's RemoveExistingProducts down the execution sequence) - see bug
117492, which I couldn't solve myself.
--
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/20190423/d9ce7f5a/attachment.html>
More information about the Libreoffice-bugs
mailing list