Re: [PATCH] up_to_date_p: treat equal mtime as outdated.

[Harald van Dijk]

On 13/04/2020 23:58, Karl Berry wrote:
> Hi Harald and all - well, Paul or Jim or any other automake worker will
> know better than me, but my reactions, FWIW:
>
>      This caused intermittent failures in automake's t/subobj.sh test, which
>
> This problem seems like the tip of the iceberg to me. With this change,
> any dependency which gets updated in the same second as the target will
> now have to get remade. Possibly looping forever, it seems to me?

Hi Karl,

A dependency is a file that needs to already exist beforehand. It is not 
going to get updated by the command that creates the target. For 
instance, for the dep configure.ac, one of the output files is 
autom4te.cache/traces.0. If configure.ac is modified, 
autom4te.cache/traces.0 needs to be updated, but the command that 
updates autom4te.cache/traces.0 does not modify configure.ac at the same 
time. My patch may cause autom4te.cache/traces.0 to be updated multiple 
times in the worst case, but that's harmless and only lasts a second at 
most.

> I have not seen a deluge of (or any) reports about timestamp precision
> being a problem before this.

It's probably pretty rare. I only saw it when running the automake 
testsuite on an otherwise idle system, and even then not reliably. I 
cannot speak for others, but that's not how I usually run the testsuite: 
normally the system is busy with other stuff as well, slowing it down 
enough for the automake test to pass.

>      runs aclocal+automake, modifies configure.ac, and immediately re-runs
>      aclocal+automake. On sufficiently fast computers, this would not update
>      the cache files.
>
> Maybe aclocal and/or automake and/or other autoprograms should just
> sleep 1 before exiting (or at whatever crucial junctures) if this
> problem must be avoided at all costs.
>
> But better -- as Paul, I guess, said, how about if up_to_date_p uses
> subsecond timestamps if available, so the < test remains unchanged?
> After all, if subsecond timestamps are not available, it's highly
> probable that it's an old machine and it's all a non-issue. --best, karl.

Leaving the check as < is wrong, but it is also inconsistent with what 
autom4te does outside of this module. From bin/autom4te.in:

 995 # Read the cache index if available and older than autom4te itself.
 996 # If autom4te is younger, then some structures such as C4che might
 997 # have changed, which would corrupt its processing.
 998 Autom4te::C4che->load ($icache_file)
 999   if -f $icache && mtime ($icache) > mtime ($0);

Note how this only reads the cache file if it's newer, not if it has the 
same mtime.

And I would not be too confident that nobody is still using file systems 
without sub-second precision on modern machines. For better or worse, 
FAT is the most universally accepted file system, and for that reason it 
is widely used. It does not even support second precision timestamps.

Cheers,
Harald van Dijk