bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: utimensat breakage


From: Jim Meyering
Subject: Re: utimensat breakage
Date: Wed, 18 Feb 2009 14:04:11 +0100

Michael Stone <address@hidden> wrote:
> It seems that libc6 doesn't have any fallback code in utimensat to
> handle older kernels that don't provide that interface (leading to
> "fuction not implemented" messages from touch or other utilities which
> use the function. This is a runtime error which depends on the kernel
> version (the regular build tests fail if building on an older kernel,
> otherwise the tests will work until you run on an older kernel). The
> attached patch checks the return code in the gl_futimens function and
> keeps falling through until it finds something that doesn't return
> ENOSYS.

Thank you.
At first glance, this looks like right.
I'll look more closely later today.

If you have any more patches that you'd like to
see in the next stable release, please send them very soon.
I plan to make a snapshot today and another Friday.
Very soon after that I want to release coreutils-7.1.

> #! /bin/sh /usr/share/dpatch/dpatch-run
> ## 77_utimensat.dpatch by Michael Stone <address@hidden>
> ##
> ## All lines beginning with `## DP:' are a description of the patch.
> ## DP: Work around glibc not handling kernel interface changes well
>
> @DPATCH@
> diff -urNad coreutils-6.12~/lib/utimens.c coreutils-6.12/lib/utimens.c
> --- coreutils-6.12~/lib/utimens.c     2008-05-29 09:21:57.000000000 -0400
> +++ coreutils-6.12/lib/utimens.c      2009-02-18 07:00:33.863932176 -0500
> @@ -78,6 +78,8 @@
>  gl_futimens (int fd ATTRIBUTE_UNUSED,
>            char const *file, struct timespec const timespec[2])
>  {
> +  int ret;
> +
>    /* Some Linux-based NFS clients are buggy, and mishandle time stamps
>       of files in NFS file systems in some cases.  We have no
>       configure-time test for this, but please see
> @@ -98,16 +100,23 @@
>    /* POSIX 200x added two interfaces to set file timestamps with
>       nanosecond resolution.  */
>  #if HAVE_UTIMENSAT
> -  if (fd < 0)
> -    return utimensat (AT_FDCWD, file, timespec, 0);
> +  if (fd < 0) {
> +    ret = utimensat (AT_FDCWD, file, timespec, 0);
> +    if (!ret || errno != ENOSYS) {
> +      return ret;
> +    }
> +  }
>  #endif
>  #if HAVE_FUTIMENS
> -  return futimens (fd, timespec);
> -#else
> +  ret = futimens (fd, timespec);
> +  if (!ret || errno != ENOSYS) {
> +    return ret;
> +  }
> +#endif
>
> -  /* The platform lacks an interface to set file timestamps with
> -     nanosecond resolution, so do the best we can, discarding any
> -     fractional part of the timestamp.  */
> +  /* If we get here, the platform lacks an interface to set file
> +     timestamps with nanosecond resolution, so do the best we can,
> +     discarding any fractional part of the timestamp.  */
>    {
>  # if HAVE_FUTIMESAT || HAVE_WORKING_UTIMES
>      struct timeval timeval[2];
> @@ -189,7 +198,6 @@
>      }
>  # endif /* !HAVE_WORKING_UTIMES */
>    }
> -#endif /* !HAVE_FUTIMENS */
>  }
>
>  /* Set the access and modification time stamps of FILE to be




reply via email to

[Prev in Thread] Current Thread [Next in Thread]