Re: glibc utimes glitch with coreutils 'touch'

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
> 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).

Thanks.  I'll probably add that.
What problem arises in coreutils if we don't detect/work-around
that difference?

> 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?

I think that the bug in glibc won't end up lasting long
enough to make it onto a significant number of systems.
And for those users who are progressive (or maybe reckless :-) enough
that they get a losing glibc, I think it's reasonable to expect
them to upgrade pretty quickly to a version with the fix.

> 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.

If this bug makes it in to wide distribution (major release,
shrink wrap, etc), then I'd most definitely go for this approach.