JDK-6224405 : REGRESSION: wrong time stamp for plugin dll files on Win98(2nd)
  • Type: Bug
  • Component: install
  • Sub-Component: install
  • Affected Version: 5.0u2
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_98
  • CPU: x86
  • Submitted: 2005-02-02
  • Updated: 2013-06-04
  • Resolved: 2005-03-16
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.
Other JDK 6
5.0u3 b06Fixed 6Fixed
Description
OS:         Windows 98 2nd edition
JDK:        tiger_u2 b05, tiger_u3 b03 (pass with tiger_u1 fcs)
JDK bundle: fail with p-bundle. for example: jre-1_5_0_02-windows-i586-p.exe
            pass with not p-bundle, for exampl:jre-1_5_0_02-windows-i586.exe

test machine: 
stardust (Win98 2nd at lab 2370 in SCA14)

How to reproduce:
====================
1. delete 7 NPJava.dll C:\Program Files\mozilla.org\Mozilla\plugins
2. install jre-1_5_0_02-windows-i586-p.exe
3. you'll see the time stamp is 1/12/69 for all NP***.dll files.
year 69 is year 2069.


last part of C:\WINDOWS\TEMP\java_install:
============================================
extracting: lib/zi/ZoneInfoMappings
Unpacking from C:\Program Files\Java\jre1.5.0_02\\lib\rt.pack to C:\Program Files\Java\jre1.5.0_02\\lib\rt.jar
com.sun.java.util.jar.pack.unpack.log.file=C:\WINDOWS\TEMP\java_install.log
unpack.deflate.hint=(not set)
com.sun.java.util.jar.pack.unpack.remove.packfile=true
com.sun.java.util.jar.pack.verbose=1
com.sun.java.util.jar.pack.unpack.modification.time=(not set)
Unpacking from C:\Program Files\Java\jre1.5.0_02\\lib\jsse.pack to C:\Program Files\Java\jre1.5.0_02\\lib\jsse.jar
com.sun.java.util.jar.pack.unpack.log.file=C:\WINDOWS\TEMP\java_install.log
unpack.deflate.hint=(not set)
com.sun.java.util.jar.pack.unpack.remove.packfile=true
com.sun.java.util.jar.pack.verbose=1
com.sun.java.util.jar.pack.unpack.modification.time=(not set)
Unpacking from C:\Program Files\Java\jre1.5.0_02\\lib\plugin.pack to C:\Program Files\Java\jre1.5.0_02\\lib\plugin.jar
com.sun.java.util.jar.pack.unpack.log.file=C:\WINDOWS\TEMP\java_install.log
unpack.deflate.hint=(not set)
com.sun.java.util.jar.pack.unpack.remove.packfile=true
com.sun.java.util.jar.pack.verbose=1
com.sun.java.util.jar.pack.unpack.modification.time=(not set)
Unpacking from C:\Program Files\Java\jre1.5.0_02\\lib\javaws.pack to C:\Program Files\Java\jre1.5.0_02\\lib\javaws.jar
com.sun.java.util.jar.pack.unpack.log.file=C:\WINDOWS\TEMP\java_install.log
unpack.deflate.hint=(not set)
com.sun.java.util.jar.pack.unpack.remove.packfile=true
com.sun.java.util.jar.pack.verbose=1
com.sun.java.util.jar.pack.unpack.modification.time=(not set)
Unpacking from C:\Program Files\Java\jre1.5.0_02\\lib\deploy.pack to C:\Program Files\Java\jre1.5.0_02\\lib\deploy.jar
com.sun.java.util.jar.pack.unpack.log.file=C:\WINDOWS\TEMP\java_install.log
unpack.deflate.hint=(not set)


###@###.### 2005-2-02 02:30:54 GMT
Comments
EVALUATION This is a known problem with rtpatch. Here is the conversation I had with the rtpatch support guy: Hi Bill, Sorry for not being more clear - the workaround is employed at Build time only. The bug in RTPatch is in the Apply mechanism; however, the only way to work around it is to avoid odd-second timestamps being input into the patch file at Build time (NEWDIR only). If you can make sure that all of the files in your NEWDIR have even-second timestamps prior to building the patch, then you will not see this error when applying the patch file. Note that an upgrade would enable you to get past this error without re-building any patch files - you would only need to start using the newer Apply engines. We do not support native 64-bit patch Build or Apply. We do license source code for Linux/Unix (which I know to have been ported to 64-bit), as well as for Windows. I am not aware of anyone who has licensed the Windows Apply source code for this purpose, however. Is this an immediate need, and if not, what is your timeframe for this requirement? Regards, Tony O- -----Original Email----- From: William Harnois Date: 02:21 PM 2/4/2005 -0500 Hi Tony, We will definately look into upgrading. In the meantime, I have a few questions about your workaround. When do we need to make sure that the timestamp seconds is even? Is it during the build when we are creating the binary difference, or during install time? Also, is this only a timestamp problem, or would this lead to other, more serious issues? Also, do you have 64-bit patching support? -Bill Tony Olivero wrote: > Hi Bill, > > Your CD-KEY indicates a version 6.50 release. This timestamp problem is a > known bug in that release that has been fixed. I recommend that you upgrade > to the latest version of RTPatch to take advantage of this bug fix, as well > as all others that have been identified since that release (3 years ago > this month). You will also be able to contact technical support via email > and voice, when on a current release. > > Please contact Paul Lemper at mailto:###@###.### or 800-826-8086 > to discuss your licensing options and pricing. > > I hope that you choose to upgrade. I would also like to provide a > workaround to you for this problem, to meet this immediate need. The > problem is caused when your NEWDIR files contain a timestamp whose seconds > value is odd. To workaround the problem, you must make sure that the > timestamp is even. Since FAT32 formatted drives work on a two-second > granularity, building on FAT32 drives effectively bypasses the problem. We > have also seen good results in transferring to a FAT32, and then back to > NTFS prior to building. Latest RTPatch does not suffer from this problem. > > If you have any questions, please call or email. > > Regards, > > Tony O- > 713-460-5600 > > -----Original Email----- > From: William Harnois > Date: 12:18 PM 2/4/2005 -0500 > > Hi, > > This is our serial number: T3XP00YCWHV5 > > We noticed a weird time stamp problem lately. If we just install the > files for our product, they are correctly dated 2005. But if we use > rtpatch, the date is set to 2069 on some of the files. Have you heard > of anything like this? > > Thanks, > Bill > We will upgrade our rtpatch to the latest version for 5.0u3 and 6.0. ###@###.### 2005-2-04 20:57:32 GMT
04-02-2005