Bug (old?) in ZipEntry?

Tue Sep 13 10:50:00 GMT 2005

>>>>Do you mind trying with the two test-archives I've attached - you're
>>>>free to ignore...
>>>>>>This is weird - with the ZIP archives that you have provided
>>>me, the output is different for Sun's JDK 1.5.0.03 and current
>>>GCJ. I think you should file a bug against the "classpath"
>>>product in the GCC Bugzilla and attach the two archives.
>>> I think I have found the problem. The "fromzip.zip" archive
> contains an additional timestamp entry for "ZipDates.java":
>> Current Location part 1 offset 43
> extra field 0x5455 (universal time), 4 header and 9 data bytes:
> 03 90 5d 21 43 f6 5d 21 43 ..]!C.]!C
> extra field 0x7855 (Unix UID/GID), 4 header and 4 data bytes:
> 20 02 11 29 ..)
>> The modification timestamp is "1126260112" which is *seconds*
> since *the standard UNIX epoch* (i.e., it is *not* a dostime).
> This is according to this document:
>> http://www.unix-ag.uni-kl.de/~conrad/krypto/pkcrack/doc/appnote.iz.txt
>> Our ZipEntry code (both in libgcj/classpath) treats it as a
> dostime, leading to the error that you have noticed.
>> Please file a bug report against classpath, including a link to
> this message, if possible.

Hereby done!
I'll make a workaround - (x-epoch1)*1000+epoch2 (maybe epoch1=epoch2)...
// Martin