Hi,
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:
1014414834150
and after zipped/jarred and then unzipped/unjarred. it has a "File.lastModified()" of:
1014414834000
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 SourceFileScanner.java 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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
