Prev: The project BIEW was renamed into BEYE
Next: 070911 Answers to your Computer question! 03
From: Decare on 25 Feb 2010 14:07

When building projects, sometimes, make complains as follows:
... has modification time in the future
It can be resolved through touching files or reset system clock.
But, I don't understand why all these happen. Any explanation in
detail or references?

--
ego cogito ergo sum
From: John Gordon on 25 Feb 2010 15:02
In <84mxyxnnh0.fsf(a)yeah.net> Decare <decare(a)yeah.net> writes:


> When building projects, sometimes, make complains as follows:
> ... has modification time in the future
> It can be resolved through touching files or reset system clock.
> But, I don't understand why all these happen. Any explanation in
> detail or references?

One way it can happen is if you're working on a filesystem that is
shared among multiple hosts (i.e. NFS), and the system clocks on
the hosts are not in sync.

--
John Gordon A is for Amy, who fell down the stairs
gordon(a)panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

From: Rainer Weikusat on 25 Feb 2010 15:20
Decare <decare(a)yeah.net> writes:
> When building projects, sometimes, make complains as follows:
> ... has modification time in the future
> It can be resolved through touching files or reset system clock.
> But, I don't understand why all these happen. Any explanation in
> detail or references?

Make decides if a target file needs to be rebuilt by comparing the
modification timestamp of the target file with the modifications
timestamps of all its dependencies. A target file is remade when at
least one of the dependency timestamps is 'in the future' relative to
the target file timestamp. 'Has modification time in the future' means
that one of the timestamps make was looking at corresponded with a
time in the relative future of the present system time. This is BAD,
because the modification timestamp of a file corresponds with the
system time at the time of the modification, meaning, it is possible
that a modified file appears to be 'older' than an unmodified one if
the timestamp of the unmodified file is "in the future".

The usual cause for this is 'unsuitable methods of keeping the local
system time accurate' aka 'run ntpdate from cron' and/or copying files
around among networked machines whose system clocks differ
substantially, either because nothing has been done to keep their
respective clocks accurate (so they drift away from each other over
time) or because the same 'unsuitable methods of keeping the local
system time accurate' are in use, meaning, the system times drift away
from each other in however ways they happen to like and the time on
each machines jumps randomly to new value in random intervals.

The solution to this problem is to run ntpd with a proper
configuration so that the times are kept in sync.
From: Mark Hobley on 25 Feb 2010 16:08
Decare <decare(a)yeah.net> wrote:
> But, I don't understand why all these happen. Any explanation in
> detail or references?

Are you using a remote filesystem via a network?

Files may be timestamped with a different time to the system time, if the file
is being created on a network fileserver:

echo hello >/tmp/hello
date
stat -c %y /tmp/hello

Wed Apr 4 19:17:50 BST 2007
2007-04-04 19:19:14.884890560 +0100


== Cause ==

There is a slight difference between the local machine clock time and the
fileserver clock time.

== Resolution ==

Synchronize the time between the file server and the local machine, or use the
local filesystem for file manipulation.

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

 | 
Pages: 1
Prev: The project BIEW was renamed into BEYE
Next: 070911 Answers to your Computer question! 03