[Bug-gnulib] Re: glibc utimes glitch with coreutils 'touch'

[Paul Eggert]

Jim Meyering <address@hidden> writes:

> Instead, I'm adding a configure-time test of utimes, so that
> if it works, coreutils will use it.

OK, but a couple of things.  First, I would change this:

>   static struct timeval timeval[2] = {{9, 10}, {11, 12}};

to this:

>   static struct timeval timeval[2] = {{9, 10}, {999999, 999999}};

so that you can detect the problem with glibc's utimes() rounding up
in some cases (glibc after 2003-07-12).

Second and probably more important: what if coreutils is built with
one version of glibc that doesn't have this glitch, but the built
coreutils is then run and dynamically linked to another glibc version
that has the glitch?

What I was thinking of doing to attack this problem, is to invoke
syscall (SYS_utimes, 2, file, timeval) instead of utimes (file,
timeval) on hosts where the problem might occur (as determined by some
configure-time test, perhaps).  That way, I don't have to trust
glibc's implementation of utimes.  The code would fall back on utime
if the syscall fails with ENOSYS.  This is a bit draconian, though.