JDK-6855941 : 25099 specifically with Readme.txt/Copyright files
  • Type: Bug
  • Component: install
  • Sub-Component: install
  • Affected Version: 6u14
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-06-29
  • Updated: 2010-09-16
  • Resolved: 2009-11-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u18 b04Fixed 7Fixed
Related Reports
Relates :  
Description
Subject says it all.  Chris G can add the log files we've been seeing.

Comments
SUGGESTED FIX webrev: http://sa.sfbay.sun.com/projects/deployment_data/6u18/6855941.0
08-10-2009

EVALUATION The fix here is going to be to make sure the RemoveFile table is empty for update msi's and that it's full with type 3 for consumer and static installs. We need to make sure we're pruning out the target dir before we start unzipping stuff.
01-10-2009

EVALUATION I tried the following: 1. Install jre 6u18 2. Make a copy of the jre6 dir to jre6.save 3. uninstall jre 6u18 4. mv jre6.save to jre6 5. delete all files inside jre6 except for COPYRIGHT, README.txt, LICENSE 6. rerun the jre 6u18 installer to see if zipper would get an error extracting. zipper.exe just successfully overwrote all 3 files. So I think 25099 might have something more to do with a permissions issue. So I'm not thinking that adding the deletion of the files to the RemoveFile table or the iftw will solve the problem. The users who got around the 25099 issue likely rebooted their machine and then deleted the jre6 directory. I wonder how the RemoveFile table would behave if it encounters a file it can't delete due to permission issues (rather than it being locked by a process).
16-09-2009

EVALUATION Is there any evidence that making sure the installation directory (%ProgramFiles%\Java\jre6\ ) is empty does not work around Error 25099? I've seen emails that say this worked for them. I've spent many hours looking at the verbose MSI log files. I was looking at 6 sets of log files, 4 with verbose MSI logs. Three 6u15 installs, one 6u16. Two jre1.6.0_15-c-l.msi, two -c.msi. US and non-US. Errors with LICENSE, README.TXT, or COPYRIGHT files, but consistently with the same file on a machine. In two cases the same version of C:\Program Files\Java\jre6\bin\regutils.dll is already installed. In two other cases the regutils.dll installed is a lower version. The log files all contain: Program Files\Java\jre6\bin\regutils.dll; Won't Overwrite; Won't patch; Existing file is of an equal version or Program Files\Java\jre6\bin\regutils.dll; Overwrite; Won't patch; Existing file is a lower version so that confirms that %ProgramFiles%\Java\jre6\ is not empty for these customers, but I do not know why it isn't empty OR why unzip of core.zip can't overwrite the files in these cases. I've put a copy of a JRE at and get File: C:\Program Files\Java\jre6\bin\regutils.dll; Overwrite; Won't patch; Existing file is a lower version but unzip of core.zip overwrites files and thee installation is fine in my tests.
09-09-2009

EVALUATION from Bill: We need better logging with our zipper stuff, to print out the state of the file when we encounter this error. Is it locked?...what are the permissions of it vs our permission level, etc.
09-09-2009

EVALUATION Error 25099 was caused by README.txt and COPYRIGHT in the installation folder (default install directory: C:\Program Files\Java\jre6\) I was forwarded a number of user log files. Of the java_install.log files I received, 4 had an error with README.txt, 4 with an error with COPYRIGHT, and a third with no obvious error. (See the ErrorTwoFiveONineNineWith6u14 wiki.) Support: I've asked support for some verbose MSI logs along with the java_install.log. In cases where users will re-run the install with logging, have them run JavaSetup6u??.exe /Lv* %TEMP%\jreMSI.log and if the Error 25099 is reproducible, have them send %TEMP%\jreMSI.log and %TEMP%\java_install.log Java.com: MaryK created a wiki page with the comments from java.com where users to our english pages submitted a comment with the string '25099'. The table includes the url (mainly windows IE page), the user agent string, the comment and the IP address. https://confluence.sfbay.sun.com:8443/confluence/display/dotsun/error+25099+Comments+java.com Of the 29 comments, the user agent string tells us 24 were on XP, 5 on Vista, 19 on IE 8, and 4 had some AOL version of a browser. We have not been able to reproduce in house. User agent data has a high number of Windows XP and IE 8, but we were not able to reproduce on Windows 7 / IE 8 systems. Next steps: When the error 25099 occurs in the MSI: Check to see if the file(s) exist. Check to see if they are locked / can be overwritten. Move the zipper code to a dll and add better error logging when a Windows API call fails. Log processes running / system information. Pinging some other value before / instead of pinging 1603 could quantify the occurance of Error 25099, other than just less that the # of 1603's.
07-08-2009