Bug 23854 - ZipEntry handles additional timestamp in zip-file incorrectly
Summary: ZipEntry handles additional timestamp in zip-file incorrectly
Status: RESOLVED FIXED
Alias: None
Product: classpath
Classification: Unclassified
Component: classpath (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: 0.96
Assignee: Andrew John Hughes
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-09-13 08:51 UTC by Martin Egholm
Modified: 2008-03-05 21:06 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2007-10-06 22:38:17


Attachments
The zip-file created with Cygwin's "zip" reproducing the bug (538 bytes, application/octet-stream)
2005-09-13 08:53 UTC, Martin Egholm
Details
Produced with "WinZip" with same content as other zip-file, but correct timestamp returned from ZipEntry (509 bytes, application/octet-stream)
2005-09-13 08:56 UTC, Martin Egholm
Details
Test case (404 bytes, text/plain)
2007-10-07 22:52 UTC, Andrew John Hughes
Details
Fix for seconds to milliseconds (295 bytes, patch)
2007-10-07 22:53 UTC, Andrew John Hughes
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Egholm 2005-09-13 08:51:23 UTC
A zip-file created with cygwin's "zip" command contains an additional timestamp
entry for the modification-date. However, this timestamp is in seconds since the
UNIX epoch. However, ZipEntry interprets this a dostime, so when getTime() is
invoked, a wrong number is returned. 

See the discussion thread on:
http://gcc.gnu.org/ml/java/2005-09/msg00070.html

A sample source illustrating it is given below, and the output is shown below
when tested on two zip-files - one created with cygwin's zip, and one with WinZip:

=== GCJ ===
# ./zipdates fromzip.zip
ZipDates.java   date: 313906034000      Thu Dec 13 03:07:14 GMT-01:00 1979
# ./zipdates fromwinzip.zip
ZipDates.java   date: 1126270914231     Fri Sep 09 12:01:54 GMT-01:00 2005 

The test-application is compiled using GCJ, and is confirmed by Ranjit Mathew to
be present in a "recent" version.
I'll attach the two zip-files...

=== ZipDates ===
/*
 * Feel free to use this source.
 * Martin Egholm - 2005.
 */
package men.zipdate;

import java.io.IOException;
import java.util.Enumeration;
import java.util.zip.ZipEntry;
import java.util.zip.ZipFile;

public class ZipDates
{
  public static void main(String[] args) throws IOException
  {
    if (args.length < 1)
    {
      System.out.println("Missing filename argument...");
      return;
    } // if
    else
    {
      ZipFile zf = new ZipFile(args[0]);

      Enumeration entries = zf.entries();

      while (entries.hasMoreElements())
      {
        ZipEntry entry = (ZipEntry) entries.nextElement();
        System.out.println(entry.getName() + "\tdate: " + entry.getTime()
            + "\t" + new java.util.Date(entry.getTime()));
      } // while
    } // else
  } // main
} // ZipDates
Comment 1 Martin Egholm 2005-09-13 08:53:12 UTC
Created attachment 9715 [details]
The zip-file created with Cygwin's "zip" reproducing the bug
Comment 2 Martin Egholm 2005-09-13 08:56:37 UTC
Created attachment 9716 [details]
Produced with "WinZip" with same content as other zip-file, but correct timestamp returned from ZipEntry
Comment 3 Ranjit Mathew 2005-09-13 11:20:17 UTC
See also:

  http://gcc.gnu.org/ml/java/2005-09/msg00072.html
Comment 4 Andrew John Hughes 2007-10-06 22:38:17 UTC
This bug still exist in current CVS (future 0.96).  Seems to be fixed if we don't parse the UT block.
Comment 5 Andrew John Hughes 2007-10-06 23:10:26 UTC
The main issue seems to be that the UT block stores the modification time in seconds as an integer, and this is then passed as milliseconds to the calendar class.  Multiplying it by 1000 beforehand gives a more sensible result, but we still seem to be out by 1 hour.

OpenJDK:
java ZipDates with_cygwin.zip
ZipDates.java   date: 1126601898000     Tue Sep 13 09:58:18 BST 2005

CACAO+Classpath CVS:
ZipDates.java   date: 1126598298000     Tue Sep 13 08:58:18 British Summer Time 2005

Not sure if this is a bug in our zip implementation or in our date handling.

Comment 6 cvs-commit@developer.classpath.org 2007-10-07 18:49:10 UTC
Subject: Bug 23854

CVSROOT:	/cvsroot/classpath
Module name:	classpath
Changes by:	Andrew John Hughes <gnu_andrew>	07/10/07 18:48:46

Modified files:
	.              : ChangeLog 
	java/util/zip  : ZipEntry.java 

Log message:
	2007-10-07  Andrew John Hughes  <gnu_andrew@member.fsf.org>
	
		PR classpath/23854:
		* java/util/zip/ZipEntry.java:
		(parseExtra()): Pass time to setTime in milliseconds
		rather than seconds by multiplying by 1000.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpath&r1=1.9398&r2=1.9399
http://cvs.savannah.gnu.org/viewcvs/classpath/java/util/zip/ZipEntry.java?cvsroot=classpath&r1=1.19&r2=1.20



Comment 7 Andrew John Hughes 2007-10-07 22:50:35 UTC
unzip -l gives the same result as Classpath:

unzip -l with_cygwin.zip
Archive:  with_cygwin.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
      806  09-13-05 08:58   ZipDates.java
 --------                   -------
      806                   1 file

Not sure what the JDK is doing, maybe this is a bug there?  Can someone with a different timezone test the ZipDates code on OpenJDK and tell me the result?  Or can the original submitter please confirm this is the correct time.  Thanks.
Comment 8 Andrew John Hughes 2007-10-07 22:52:13 UTC
Created attachment 14318 [details]
Test case
Comment 9 Andrew John Hughes 2007-10-07 22:53:00 UTC
Created attachment 14319 [details]
Fix for seconds to milliseconds
Comment 10 Andrew John Hughes 2008-03-05 21:06:11 UTC
I'm assuming this is now fine.