On 2009-07-30, Jim Meyering <j...@meyering.net> wrote:
> I noticed (by inspection, since I was looking at AM_SANITY_CHECK)
> the unconditional 1-second sleep in coreutils' configure script,
> and realized that it'd be easy to avoid it on modern systems:
> either because configure was created more than a second before,
> or because the file system supports subsecond time stamps.
The first case is a nice gain, especially as it's likely to be the case for
most invocations of configure.
But in the latter case, what if stat is available, and the filesystem supports
subsecond granularity, but ls only works to the second? Say coreutils is
installed in a director later in PATH, so stat comes from coreutils but ls
is the system one.
It seems that the stat test would be fine, but then "ls -t" would see the files
as having the same time stamp, and then the ordering depends on how you invoke
configure:
$ cd /tmp
$ touch configure conftest.file
$ ls -t ./configure conftest.file
./configure conftest.file
$ ls -t /tmp/configure conftest.file
conftest.file /tmp/configure
In the latter case, configure would report that newly created files were older
than distributed ones, although rerunning it more than a second later would
magically work.
Or perhaps there simply aren't systems where a filesystem supports subsecond
granularity and coreutils can handle this but the system ls doesn't, making
this a rather theoretical worry.
Cheers,
Olly
