[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:
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Emacs-diffs] /srv/bzr/emacs/trunk r112477: Merge from gnulib.,
Paul Eggert <=