Date: Wed, 6 May 1998 13:30:24 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Anton Helm <tony AT nt DOT tuwien DOT ac DOT at>
cc: djgpp AT delorie DOT com
Subject: Re: Make "Clock Skew" problem.
In-Reply-To: <3.0.5.32.19980505154335.00947950@dictator.nt.tuwien.ac.at>
Message-ID: <Pine.SUN.3.91.980506132448.1846F-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Tue, 5 May 1998, Anton Helm wrote:

> I have some other experiences with "File has timestamp in the future":
> 
> 1) I frequently copy my source codes between my PC and a unix host by
> means of SAMBA. I observed that the files I edited on the same day get
> a timestamp of **several hours in the future** when being copied to the
> unix host, while older file time stamps remain intact.
[snip]
> The system clock of WinNT4.0 and the time used in a DOS-box had a difference
> of 27 minutes, which resulted in the same error message. Rebooting the PC
> removed the 27 minutes "skew".

These are exactly the cases for which that warning was designed.  If the 
clocks aren't in sync, the whole chain of Make's decisions about what 
targets to rebuild is subject to severe errors.  If there were a way to 
detect clock skews in the other direction (which are by far more 
dangerous, btw), it should have also triggered a warning.

The GNU Make maintainer intends to implement an alternative method of 
deciding which targets to rebuild, which will be based on file contents 
rather than time stamp.  This will eliminate such problems altogether 
(but probably introduce others ;-).  I don't know if the next release 
(due out soon) will include this feature, or how (or even if) will it 
work on MS-DOS.