Apache OpenOffice (AOO) Bugzilla – Issue 119424
Microsoft VC Redistributable leaves files after install
Last modified: 2012-08-27 16:19:50 UTC
Created attachment 77610 [details] Screen shot of the c drive after install OO 3.4 The current installer on Windows of OpenOffice 3.4 installs the Microsoft Redistributable C++ 2008 package which has a bug that leaves the install files on the C: root drivve after the install has finished. Please update the OpenOffice installer to use the latest VC 2008 C++ redistributable package.
See also: https://issues.apache.org/ooo/show_bug.cgi?id=111420 and http://support.microsoft.com/kb/950683
List of files left in C:\ from AOO3.4 VC++ installer: ------------------------------------------------------ 11/04/2008 10.07 3.820 eula.1028.txt 11/04/2008 10.07 15.428 eula.1031.txt 11/04/2008 10.07 10.058 eula.1033.txt 11/04/2008 10.07 12.246 eula.1036.txt 11/04/2008 10.07 13.912 eula.1040.txt 11/04/2008 10.07 5.868 eula.1041.txt 11/04/2008 10.07 5.970 eula.1042.txt 11/04/2008 10.07 10.134 eula.1049.txt 11/04/2008 10.07 3.814 eula.2052.txt 11/04/2008 10.07 12.936 eula.3082.txt 11/04/2008 10.07 1.110 globdata.ini 11/04/2008 08.03 562.688 install.exe 11/04/2008 10.07 843 install.ini 11/04/2008 08.03 76.304 install.res.1028.dll 11/04/2008 08.03 96.272 install.res.1031.dll 11/04/2008 08.03 91.152 install.res.1033.dll 11/04/2008 08.03 97.296 install.res.1036.dll 11/04/2008 08.03 95.248 install.res.1040.dll 11/04/2008 08.03 81.424 install.res.1041.dll 11/04/2008 08.03 79.888 install.res.1042.dll 11/04/2008 10.09 93.200 install.res.1049.dll 11/04/2008 08.03 75.792 install.res.2052.dll 11/04/2008 08.03 96.272 install.res.3082.dll 11/04/2008 10.07 5.686 vcredist.bmp 11/04/2008 10.09 3.797.292 VC_RED.cab 11/04/2008 10.11 233.472 VC_RED.MSI Strangely the VC++redistributable supplied with 3.4 is older than 3.3: Microsoft Visual C++ 2008 Redistributable - x86 9.0.30411 (AOO3.4) Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.4148 (OOO3.3)
set release blocker flag to 3.4.1
So, the temporary file issue is caused by a bug of old version Visual C++ 2008 Redistributable Package. Current AOO does not keep the VCRedist package in the source tree, the version of the VCRedist package supplied with 3.4 was determined by the package version in the build environment. Can we close this issue? or we should add some checking code in the build script? (In reply to comment #1) > See also: https://issues.apache.org/ooo/show_bug.cgi?id=111420 and > http://support.microsoft.com/kb/950683
Just for memo, these left files also appear in the Windows 8 Certification ACK scan report installer section.
It was my fault that the AOO 3.4 release binary release packages for Windows contain the "old" Microsoft Visual C++ 2008 Redistributable. I know have downloaded the newest ones (x86 and x64) using [1]. There version is 9.0.30729.6161 [1] http://www.microsoft.com/en-us/download/search.aspx?q=Microsoft%20Visual%20C%2b%2b%202008%20Redistributable%20Package&p=0&r=10&t=&s=availabledate~Descending I am keeping this issue opened as long as we have verified that we are packaging the newest ones.
A developer snapshot for coming AOO 3.4.1 is available - https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds Please check, if I have packed now the right Microsoft Visual C++ 2008 Redistributable. Thx in advance.
Verify fixed on 3.4.1 DEV snapshot rev.1351960 Platform is Win7 X64
Verify fixed on 3.4.1 DEV snapshot r1351960 Platform is WinXP EN
*** Issue 120113 has been marked as a duplicate of this issue. ***
i want to stress that the bug is not only that files are not deleted. Also from my best belief, files should NEVER have landed in root folder. You have %TEMP%, you have that OOO-unpacked folder on desktop. Root folder should be polluted never. IOW those are two bugs in one ticket :-P
Another thing to stress is that to me drive D:\ was polluted. So correct formula probably would be not "leaves the install files on the C: root drivve " but a "leaves the install files on the root of drive installer been run from" That leads as to a bug estimate. Common to installer scripts. I think there is some variable, let's name it %VCRT_ROOT% And vcrt installer is unpacked to kinda "%VCRT_ROOT%\%in-archive-path-for-file-being-unpacked%" Now if for some reason %VCRT_ROOT% fails to initialize and remains empty u have exactly that - unpacking to the root of current drive. Then if cleanup-code expects VCRT to be unpacked to predefined folder - it wipes that folder, and if VCRT was unpacked there it would be deleted as well. But... it was unpacked to another place and survives under radar.
"sudo rf -rm $(var-i-thought-has-value)\*" if u know what i mean :-) PS: those who do not know - NEVER EVER do it :-)
close this defect
set target milestone AOO 3.4.1
verified, 3.4.1 use the last VCredistributable Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.6161 and no stale files around in root