I've known about a strange touch-related failure for a few weeks,
but since it arises only on systems with old and relatively
unusual kernels, I haven't worried about it:
http://bugzilla.redhat.com/442352
but now that coreutils-6.12 has come into service on more
systems, it's becoming a problem:
http://bugzilla.redhat.com/449910
so this change may be warranted.
This is quite ugly, but I don't see a better way.
>From 6de3d038640931aaf9bbb4c0ed1fc9bc8f9a05bf Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Wed, 4 Jun 2008 19:32:50 +0200
Subject: [PATCH] utimens.c: work around (Xen-related?) kernel bug
* lib/utimens.c (gl_futimens) [HAVE_UTIMENSAT]: Work around what
appears to be a kernel bug that causes utimensat to return 280
instead of 0, indicating success.
---
lib/utimens.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/lib/utimens.c b/lib/utimens.c
index 134310b..e74fa2d 100644
--- a/lib/utimens.c
+++ b/lib/utimens.c
@@ -103,6 +103,16 @@ gl_futimens (int fd ATTRIBUTE_UNUSED,
if (fd < 0)
{
int result = utimensat (AT_FDCWD, file, timespec, 0);
+ /* 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.
+ FIXME: remove in 2010 or whenever the offending kernels
+ are no longer in common use. */
+ if (result == 280)
+ result = 0;
+
if (result == 0 || errno != ENOSYS)
return result;
}
--
1.5.6.rc1.2.g5648b
