ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martijn Kruithof ...@kruithof.xs4all.nl>
Subject Re: New COPY granularity breaks builds on Windows 2000
Date Tue, 08 Mar 2005 23:09:16 GMT
I had yet another thought,

why don't we assume (unless specified otherwise) that the filesystem 
timestamp granularity of all involved filesystems is the same (we 
currently already do, and tie some pretty strange conclusions to that fact).
That way we should be able to not take into account the granularity of 
the filesystems at all. (e.g. on both files we should assume the time is 
rouded either up or down).
Example file system granularity is 2 seconds
This means that files are stored in a 2 second granularity, eg the 
number of seconds will be either 0, 2, 4, 6, 8, ...
but never 1, 3, 5, 7, 9, ... (or the other way around)
A file stored at timestamp 1 will never occur as the files are stored in 
a 2 second granularity.
A file stored at timestamp 0 is older than a file stored at timestamp 2.
A file stored at timestamp 2 is newer than a file stored at timestamp 0.
If two files have the same timestamp we cannot say which one is newer.
This all has nothing to do with the granularity. The granularity could 
be taken into account when comparing a file timestamp with a non file 
timestamp (e.g. as when checking for future modification dates), or when 
comparing timestamps of different file systems. If that where the goal 
however we indeed should not use an os based granularity, but for 
instance always use 2 seconds as the highest normal value.

So I would propose to consider a destination out of date if the source 
timestamp is newer  than the destination timestamp, regardless of the 
filesystem granularity.

We still need the granularity for the test cases though, and maybe for 
comparing with checking wit non file timestamp based times.
We should consider how to handle targets that have the same timestamp as 
the source for non copy like tasks, which may preserve the timestamp. 
e.g. for a compile taks maybe we should consider the destination out of 
date if the source has the same timestamp as the destination.

Martijn


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message