----- Original Message ----- From: "Don Taylor" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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
