Subject: bug#7324: coreutils on Solaris 10

From: Eric Blake <[email-masked]>
Date: Wed, 03 Nov 2010 12:33:59 -0600

On 11/03/2010 11:25 AM, Eric Blake wrote:
> [adding bug-gnulib]

On 11/03/2010 11:39 AM, Eric Blake wrote:
> * m4/utimens.m4 (gl_UTIMENS): Include correct headers.
>
> Signed-off-by: Eric Blake <[email-masked]>
> ---
>
> Well this is embarrassing.  The configure test for whether
> futimesat(,NULL,) works failed because O_RDWR was not
> declared.  I'm pushing this, then retesting to see if
> Solaris 10 still has issues with setting fd times.
>
>  ChangeLog     |    5 +++++
>  m4/utimens.m4 |    3 ++-
>  2 files changed, 7 insertions(+), 1 deletions(-)

I've confirmed that with this fix, the latest gnulib now passes all
time-setting tests except those related to symlink times.  I'm now in
the process of testing coreutils on the same machine to see if the fixed
gnulib test makes touch start working again.

> 
> 
> It looks like Solaris 10 may have broken their hack where
> futimesat(fd,NULL,time) could set the timestamps of an open fd, which
> coreutils is relying on since futimens and utimensat do not exist on
> that platform.

Thankfully, the futimesat hack still works.  What didn't work was that
the bogus .m4 test (broken since gnulib commit 0883405c in Nov 2009)
made coreutils skip using futimesat() in the first place, and its
fallback to even older utimes-style functions are triggering failures.
But since we should be using futimesat rather than older fallbacks, it
shouldn't matter if those older fallbacks (think utimes()) were recently
broken.

Still, that only definitively explains why coreutils 8.1 through 8.6
would fail; it doesn't necessarily speak to the observed failure on
5.97, nor does it answer what the behavior with 6.0 through 8.0 would
be, because those versions all encountered older implementations of the
gnulib time-setting fallbacks.

-- 
Eric Blake   [email-masked]    +1-801-349-2682
Libvirt virtualization library http://libvirt.org