Re: inappropriate warning on Solaris?

[Paul Smith]

On Thu, 2010-12-09 at 17:25 -0500, David Boyce wrote:
> On Thu, Dec 9, 2010 at 5:13 PM, Paul Smith <address@hidden> wrote:
> > On Wed, 2010-12-08 at 21:23 -0500, David Boyce wrote:
> >> As shown, the target does have a relatively hi-res timestamp but the
> >> prereq is even higher (001666000 vs 001666797). Essentially, Solaris
> >> cp -p chops off just the nanosecond part. It looks to me like make's
> >> algorithm for deciding to give a warning is too simplistic and/or
> >> Linux-centric. Is this a minor bug or am I missing something?
> >
> > It's not about whether a timestamp is higher; it's about whether it's
> > high-resolution (that is, the sub-second part of the timestamp is set)
> > or not.
> 
> Right, I understand, but where is the official definition of "low" and
> "high" resolution? On Solaris, apparently, "high" means 9 decimal
> places and "low" means 6. You (make) are assuming that "low" means 0
> decimal places. Seems to me this warning should either be adjusted per
> platform or removed, because as far as I can see I'm using it
> correctly and being told that I'm not,

I'm not sure I understand the question.  Neither I nor make have any
idea what "resolution" means for a given OS so it cannot be adjusted per
platform.  Also the resolution is based on the type of filesystem, not
the OS; on Linux for example some filesystems do support high-resolution
times and some don't.  Even on Solaris, NFSv3 (IIRC) does not support
it. 

And even if we could test everything there's no reasonable way to
determine whether .001666 means that you have only 6 digits of accuracy,
or if you really have 9 digits of accuracy (or more) and the last 3
digits just happened to be 0 when you ran the stat.

The way make works is, if you don't set low-resolution then the full
resolution of the timestamp available is used, whatever that is.  If you
just have traditional seconds, that's what we use.  If you have
nanosecond support, that's what we use.

If you do set low-resolution then the timestamp is assumed to be
per-second and any precision beyond that is not used.


The real error here is in cp and similar tools which purport to preserve
timestamps, but don't preserve sub-second stamps when they're available.
Of course I realize it's easier to fix make than to fix those tools...
but just so we're clear where the REAL bug is :-).  Until the real bug
is fixed this issue will continue to be a major hassle.

As I said above it's possible that make should ignore the situation
where a file is defined to have a low-precision timestamp but doesn't.
That would "solve" your problem by doing away with the warning message.
But we have to think carefully about what problems, if any, that might
introduce.