ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <stev...@iseran.com>
Subject Re: Bug ID 4479398 may affect uptodate task
Date Fri, 17 Aug 2001 22:56:10 GMT

----- Original Message -----
From: "Don Taylor" <donald_l_taylor_jr@yahoo.com>
To: <ant-dev@jakarta.apache.org>
Sent: Thursday, August 16, 2001 06:33
Subject: Bug ID 4479398 may affect uptodate task


> You can view the report here:
>
> http://developer.java.sun.com/developer/bugParade/bugs/4479398.html
>
> I don't subscribe to this group so I won't see your feedback. I thought
> I'd pass this along as an FYI so that maybe the Ant documentation can
> be updated to warn about this problem when using the uptodate task.
>
> As a background, I wasn't using *just* the uptodate task. When I saw
> that a file was out of date, using the uptodate task, I was copying the
> file over using the 'preservelastmodified=yes' option.
> preservelastmodified uses File.lastModified() to get the date of the
> source and File.setLastModified() to set the date on the destination. I
> was receiving 994769776896 from the source, because it was on an NT
> system, but when setting on the destination (which was a Win95 and
> Linux workstation) it became 994769776000. So when the process was
> repeated it still showed the files being out of date.

This is going to be hard to fix. The problem really boils down to timestamp
resolution on different file systems. Plus there is the perennial issue of
clock synchronisation between servers -even if the time granularity is the
same, if one box is a few minutes out (or even 8 hours out!), you can have
plenty of fun.

My recommendation is 'dont build across networked file systems'.

-stev


Mime
View raw message