Re: [PATCH] utimens.c: correct yesterday's kernel bug work-around

[Jim Meyering]

Ondřej Vašík <address@hidden> wrote:
> sorry for not writing the patch myself as I promised, had some troubles
> with git clone before leaving office.
>
> Jim Meyering wrote:
>> Based on your description, I wrote the following.
>> Does it solve the problem?
>
> Yep, the patch is almost the same as I have commited and built in Fedora
> Rawhide and additionally attached to  RHBZ #449910 as
> https://bugzilla.redhat.com/attachment.cgi?id=308560 . The only
> difference is additional test case (which checks correct preserving of
> time in cp and touch) and a few differences in comments (will change
> that 0/success to -1/failure in next Rawhide build). I think as the
> problem is likely only very rare (and probably only Fedora building
> system specific), test case is not necessary and it could be kept as it
> is until it will get fixed in koji xen kernel.

Thanks for confirming.
I've pushed this:

>From 98401994e4061fc54b2a94fa254a42c9dd01ce3c Mon Sep 17 00:00:00 2001
From: Jim Meyering <address@hidden>
Date: Fri, 6 Jun 2008 18:20:14 +0200
Subject: [PATCH] utimens.c: correct kernel bug work-around
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Ondřej Vašík found that the invalid return value of 280 indicates
failure, not success, and the kernel bug we're trying to work
around affects not just the utimensat call, but also the fallback
futimens call.
* lib/utimens.c (gl_futimens) [HAVE_UTIMENSAT]: Simulate failure,
not success.
[HAVE_FUTIMENS]: Use the same work-around, here.
---
 ChangeLog     |   12 ++++++++++++
 lib/utimens.c |   13 +++++++++----
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 07026ff..8eb88b0 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,15 @@
+2008-06-09  Jim Meyering  <address@hidden>
+       and Ondřej Vašík  <address@hidden>
+
+       utimens.c: correct kernel bug work-around
+       Ondřej Vašík found that the invalid return value of 280 indicates
+       failure, not success, and the kernel bug we're trying to work
+       around affects not just the utimensat call, but also the fallback
+       futimens call.
+       * lib/utimens.c (gl_futimens) [HAVE_UTIMENSAT]: Simulate failure,
+       not success.
+       [HAVE_FUTIMENS]: Use the same work-around, here.
+
 2008-06-08  Bruno Haible  <address@hidden>

        * lib/acl-internal.h: Add me as co-author.
diff --git a/lib/utimens.c b/lib/utimens.c
index d80445c..708de10 100644
--- a/lib/utimens.c
+++ b/lib/utimens.c
@@ -103,17 +103,17 @@ gl_futimens (int fd ATTRIBUTE_UNUSED,
   if (fd < 0)
     {
       int result = utimensat (AT_FDCWD, file, timespec, 0);
-#ifdef __linux__
+# ifdef __linux__
       /* Work around what might be a kernel bug:
          http://bugzilla.redhat.com/442352
          http://bugzilla.redhat.com/449910
          It appears that utimensat can mistakenly return 280 rather
-         than 0 to indicate success.
+         than -1 upon failure.
          FIXME: remove in 2010 or whenever the offending kernels
          are no longer in common use.  */
       if (0 < result)
-        result = 0;
-#endif
+        errno = ENOSYS;
+# endif

       if (result == 0 || errno != ENOSYS)
         return result;
@@ -122,6 +122,11 @@ gl_futimens (int fd ATTRIBUTE_UNUSED,
 #if HAVE_FUTIMENS
   {
     int result = futimens (fd, timespec);
+# ifdef __linux__
+    /* Work around the same bug as above.  */
+    if (0 < result)
+      errno = ENOSYS;
+# endif
     if (result == 0 || errno != ENOSYS)
       return result;
   }
--
1.5.6.rc1.23.g2f46