Bug (old?) in ZipEntry?

[Martin Egholm Nielsen]

>>>>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