Paul Eggert wrote:
> On 09/18/11 12:11, Jim Meyering wrote:
>> Since kFreeBSD also lacks /proc/self/fd support, this has the
>> drawback of making getcwd non-thread-safe, and making it possible
>> that getcwd will exit under some unusual conditions. But neither
>> of those matter to coreutils,
>
> I doubt whether they matter to anyone else. POSIX says getcwd must
> be thread-safe, but I expect that this is because the POSIX folks
> haven't thought things through: surely common getcwd implementations
> mess up if some other thread is merrily issuing chdir calls
> while getcwd is running.
>
> The "unusual conditions" are the usual business with file
> descriptor drought, or if the current directory is searchable
> but unreadable, right? For that, I expect the emulation would
> be OK as well.
>
> Maybe we could define HAVE_OPENAT_SUPPORT to be one if either
> openat exists, or the openat module is in use? That might be
> a more-conservative fix than simply assuming HAVE_OPENAT.
Good idea.
I confirmed that this solves the problem:
>From 9475bc27f46634d92b25cf0578210ea19f759fcc Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyer...@redhat.com>
Date: Mon, 19 Sep 2011 09:48:35 +0200
Subject: [PATCH] getcwd: don't fail in a deep directory on a system without
openat
Before this change, getcwd would fail when called from a directory
of depth PATH_MAX / 3 or greater. That was due to the fact that
the non-openat implementation used "..", "../..", "../../..", etc.
to access ancestor directories. With too many, that string would
be longer than PATH_MAX.
* lib/getcwd.c (HAVE_OPENAT_SUPPORT): Define also when we are
using gnulib's openat replacement.
* m4/openat.m4: Set GNULIB_OPENAT, so getcwd.c knows when
we're using the replacement function.
---
ChangeLog | 13 +++++++++++++
lib/getcwd.c | 7 ++++---
m4/openat.m4 | 3 +++
3 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index ff1985b..50a43e8 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,16 @@
+2011-09-19 Jim Meyering <meyer...@redhat.com>
+
+ getcwd: don't fail in a deep directory on a system without openat
+ Before this change, getcwd would fail when called from a directory
+ of depth PATH_MAX / 3 or greater. That was due to the fact that
+ the non-openat implementation used "..", "../..", "../../..", etc.
+ to access ancestor directories. With too many, that string would
+ be longer than PATH_MAX.
+ * lib/getcwd.c (HAVE_OPENAT_SUPPORT): Define also when we are
+ using gnulib's openat replacement.
+ * m4/openat.m4: Set GNULIB_OPENAT, so getcwd.c knows when
+ we're using the replacement function.
+
2011-09-14 Martin von Gagern <martin.vgag...@gmx.net>
maint.mk: avoid warnings from perl about missing files
diff --git a/lib/getcwd.c b/lib/getcwd.c
index cf15521..f810161 100644
--- a/lib/getcwd.c
+++ b/lib/getcwd.c
@@ -27,9 +27,10 @@
#include <fcntl.h> /* For AT_FDCWD on Solaris 9. */
-/* If this host provides the openat function, then enable
- code below to make getcwd more efficient and robust. */
-#ifdef HAVE_OPENAT
+/* If this host provides the openat function or if we're using the
+ gnulib replacement function, then enable code below to make getcwd
+ more efficient and robust. */
+#if defined HAVE_OPENAT || defined GNULIB_OPENAT
# define HAVE_OPENAT_SUPPORT 1
#else
# define HAVE_OPENAT_SUPPORT 0
diff --git a/m4/openat.m4 b/m4/openat.m4
index 43da4f2..05a6bd3 100644
--- a/m4/openat.m4
+++ b/m4/openat.m4
@@ -51,6 +51,9 @@ AC_DEFUN([gl_FUNC_OPENAT],
fi
gl_FUNC_FCHOWNAT
gl_FUNC_FSTATAT
+
+ dnl This is tested at least via getcwd.c.
+ gl_MODULE_INDICATOR([openat])
])
# gl_FUNC_FCHOWNAT_DEREF_BUG([ACTION-IF-BUGGY[, ACTION-IF-NOT_BUGGY]])
--
1.7.7.rc0.362.g5a14
