ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeffrey Jensen" <>
Subject File timestamp changes with unjar and unzip
Date Mon, 25 Feb 2002 23:21:49 GMT

After unzipping/unjarring a file, the time stamp on the resulting file is nearly the same
as the original file, but not quite.  As viewed through the OS, the time stamp appears the
same.  However, it appears the zip technology rounds/truncates the value(?).

For example, in my research, the original file has a "File.lastModified()" of:
and after zipped/jarred and then unzipped/unjarred. it has a "File.lastModified()" of:

for a difference of the trailing "150".  

This extraction difference occurs with Ant tasks and WinZip.  I am using Ant 1.4.1 and experience
the behavior on Windows and Solaris.

This of course makes <uptodate> think the target is always out of date, when it may
not be out of date.

Has anyone else had this trouble and found a workaround?

I searched through the Ant bugzilla db, but didn't see anything on this.  I also looked at
the code to review the compare, and of course that is simple and fine:

...if (src.lastModified() > dest.lastModified())

A possible programming solution is to change the compare to ignore the last 3 digits (simply
divide by 1000?), if that would cause no ill affects on all OS'.

A workaround could be to use tar and gzip tasks instead.  I have not tested this yet.  We
would prefer to stay with zip/jar.

If there is not a workable programming change, it appears the only help is a note as to the
behavior and possibly a suggestion to  use tar/gzip (needs testing first).  If so, I could
submit a brief note added to the appropriate Ant task docs as to this behavior.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message