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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to