[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sub-second time stamp issues

From: Eric Blake
Subject: Re: sub-second time stamp issues
Date: Mon, 11 Jan 2010 05:55:47 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090812 Thunderbird/ Mnenhy/

According to Ralf Wildenhues on 1/10/2010 11:44 AM:
>> That can hurt user-written makefile rules that use `cp -p' or `touch
>> -r'.  sanity.m4 can't help it really, because this can at best cause
>> spurious rebuilds of all kinds of things, and at worst not cause
>> updating of some targets.
> Proposed patch for the Autoconf manual.  OK?

I'm okay with the patch, after you add a couple more points of clarification:

>  Traditionally, file timestamps had 1-second resolution, and @samp{cp
>  -p} copied the timestamps exactly.  However, many modern file systems
>  have timestamps with 1-nanosecond resolution.  Unfortunately, @samp{cp
> --p} implementations truncate timestamps when copying files, so this
> -can result in the destination file appearing to be older than the
> +-p} implementations either truncate or round timestamps when copying files,
> +so this can result in the destination file appearing to be older than the
>  source.

I'd like to see a mention that POSIX requires truncation, and that systems
that round are not (yet) POSIX-compliant.

> -
> +To avoid issues with rounded timestamps, you might need to introduce
> address@hidden 1} in rules depending on targets that are created with
> address@hidden -p} and @samp{touch -r}, to avoid @command{make} seeing them
> +as older than their prerequisites.  Since this is error-prone, such
> +rules are best avoided.

With gnulib, we've empirically discovered that using sleep 0.02 (20
milliseconds, on platforms where sleep(1) and/or the shell has access to
subsecond sleep) is sufficient to avoid the bulk of the out-of-date
issues, rather than waiting the full second.  But then we get into the
portability of how to specify sub-second sleeps.  So I don't know if
adding any text along those lines is worthwhile, or just adds bulk to the
documentation with no benefit.

Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]