emacs-diffs
[Top][All Lists]
Advanced

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

[Emacs-diffs] /srv/bzr/emacs/trunk r112477: Merge from gnulib.


From: Paul Eggert
Subject: [Emacs-diffs] /srv/bzr/emacs/trunk r112477: Merge from gnulib.
Date: Mon, 06 May 2013 06:37:42 -0700
User-agent: Bazaar (2.6b2)

------------------------------------------------------------
revno: 112477
committer: Paul Eggert <address@hidden>
branch nick: trunk
timestamp: Mon 2013-05-06 06:37:42 -0700
message:
  Merge from gnulib.
  
  This incorporates:
  2013-04-30 utimens, utimensat: work around Solaris UTIME_OMIT bug
modified:
  ChangeLog
  lib/utimens.c
=== modified file 'ChangeLog'
--- a/ChangeLog 2013-05-01 19:28:41 +0000
+++ b/ChangeLog 2013-05-06 13:37:42 +0000
@@ -1,3 +1,8 @@
+2013-05-06  Paul Eggert  <address@hidden>
+
+       Merge from gnulib, incorporating:
+       2013-04-30 utimens, utimensat: work around Solaris UTIME_OMIT bug
+
 2013-05-01  Paul Eggert  <address@hidden>
 
        * make-dist: Keep necessary restrictions on file access.

=== modified file 'lib/utimens.c'
--- a/lib/utimens.c     2013-01-01 09:11:05 +0000
+++ b/lib/utimens.c     2013-05-06 13:37:42 +0000
@@ -216,15 +216,19 @@
   if (0 <= utimensat_works_really)
     {
       int result;
-# if __linux__
+# if __linux__ || __sun
       /* As recently as Linux kernel 2.6.32 (Dec 2009), several file
          systems (xfs, ntfs-3g) have bugs with a single UTIME_OMIT,
          but work if both times are either explicitly specified or
          UTIME_NOW.  Work around it with a preparatory [f]stat prior
          to calling futimens/utimensat; fortunately, there is not much
          timing impact due to the extra syscall even on file systems
-         where UTIME_OMIT would have worked.  FIXME: Simplify this in
-         2012, when file system bugs are no longer common.  */
+         where UTIME_OMIT would have worked.
+
+         The same bug occurs in Solaris 11.1 (Apr 2013).
+
+         FIXME: Simplify this for Linux in 2016 and for Solaris in
+         2024, when file system bugs are no longer common.  */
       if (adjustment_needed == 2)
         {
           if (fd < 0 ? stat (file, &st) : fstat (fd, &st))
@@ -236,7 +240,7 @@
           /* Note that st is good, in case utimensat gives ENOSYS.  */
           adjustment_needed++;
         }
-# endif /* __linux__ */
+# endif
 # if HAVE_UTIMENSAT
       if (fd < 0)
         {
@@ -445,15 +449,19 @@
   if (0 <= lutimensat_works_really)
     {
       int result;
-# if __linux__
+# if __linux__ || __sun
       /* As recently as Linux kernel 2.6.32 (Dec 2009), several file
          systems (xfs, ntfs-3g) have bugs with a single UTIME_OMIT,
          but work if both times are either explicitly specified or
          UTIME_NOW.  Work around it with a preparatory lstat prior to
          calling utimensat; fortunately, there is not much timing
          impact due to the extra syscall even on file systems where
-         UTIME_OMIT would have worked.  FIXME: Simplify this in 2012,
-         when file system bugs are no longer common.  */
+         UTIME_OMIT would have worked.
+
+         The same bug occurs in Solaris 11.1 (Apr 2013).
+
+         FIXME: Simplify this for Linux in 2016 and for Solaris in
+         2024, when file system bugs are no longer common.  */
       if (adjustment_needed == 2)
         {
           if (lstat (file, &st))
@@ -465,7 +473,7 @@
           /* Note that st is good, in case utimensat gives ENOSYS.  */
           adjustment_needed++;
         }
-# endif /* __linux__ */
+# endif
       result = utimensat (AT_FDCWD, file, ts, AT_SYMLINK_NOFOLLOW);
 # ifdef __linux__
       /* Work around a kernel bug:


reply via email to

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