From dbbc0c8bb39a8b92692f03491c9384d9c068b9e2 Mon Sep 17 00:00:00 2001
From: Larry Hastings <larry@hastings.org>
Date: Fri, 22 Jun 2012 19:50:21 -0700
Subject: Issue #14626: Fix buildbot issue on OpenIndiana 3.x machines. 
 (Hopefully.)

---
 Lib/os.py             | 31 +++++++++++++++++++++----------
 Modules/posixmodule.c |  7 +++++--
 2 files changed, 26 insertions(+), 12 deletions(-)

diff --git a/Lib/os.py b/Lib/os.py
index fc8b92e..b5ad1b5 100644
--- a/Lib/os.py
+++ b/Lib/os.py
@@ -179,16 +179,27 @@ if _exists("_have_functions"):
 
     _set = set()
     _add("HAVE_FACCESSAT",  "access")
-    # Current linux (kernel 3.2, glibc 2.15) doesn't support lchmod.
-    # (The function exists, but it's a stub that always returns ENOSUP.)
-    # Now, linux *does* have fchmodat, which says it can ignore
-    # symbolic links.  But that doesn't work either (also returns ENOSUP).
-    # I'm guessing that if they fix fchmodat, they'll also add lchmod at
-    # the same time.  So, for now, assume that fchmodat doesn't support
-    # follow_symlinks unless lchmod works.
-    if ((sys.platform != "linux") or
-        ("HAVE_LCHMOD" in _have_functions)):
-        _add("HAVE_FCHMODAT",   "chmod")
+    # Some platforms don't support lchmod().  Often the function exists
+    # anyway, as a stub that always returns ENOSUP or perhaps EOPNOTSUPP.
+    # (No, I don't know why that's a good design.)  ./configure will detect
+    # this and reject it--so HAVE_LCHMOD still won't be defined on such
+    # platforms.  This is Very Helpful.
+    #
+    # However, sometimes platforms without a working lchmod() *do* have
+    # fchmodat().  (Examples: Linux kernel 3.2 with glibc 2.15,
+    # OpenIndiana 3.x.)  And fchmodat() has a flag that theoretically makes
+    # it behave like lchmod().  So in theory it would be a suitable
+    # replacement for lchmod().  But when lchmod() doesn't work, fchmodat()'s
+    # flag doesn't work *either*.  Sadly ./configure isn't sophisticated
+    # enough to detect this condition--it only determines whether or not
+    # fchmodat() minimally works.
+    #
+    # Therefore we simply ignore fchmodat() when deciding whether or not
+    # os.chmod supports follow_symlinks.  Just checking lchmod() is
+    # sufficient.  After all--if you have a working fchmodat(), your
+    # lchmod() almost certainly works too.
+    #
+    # _add("HAVE_FCHMODAT",   "chmod")
     _add("HAVE_FCHOWNAT",   "chown")
     _add("HAVE_FSTATAT",    "stat")
     _add("HAVE_LCHFLAGS",   "chflags")
diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
index eb59513..1f1711d 100644
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -2696,7 +2696,8 @@ posix_chmod(PyObject *self, PyObject *args, PyObject *kwargs)
         /*
          * fchmodat() doesn't currently support AT_SYMLINK_NOFOLLOW!
          * The documentation specifically shows how to use it,
-         * and then says it isn't implemented yet.   (glibc 2.15)
+         * and then says it isn't implemented yet.
+         * (true on linux with glibc 2.15, and openindiana 3.x)
          *
          * Once it is supported, os.chmod will automatically
          * support dir_fd and follow_symlinks=False.  (Hopefully.)
@@ -2709,7 +2710,9 @@ posix_chmod(PyObject *self, PyObject *args, PyObject *kwargs)
          * and we can't do that in this nested scope.  (Macro trickery, sigh.)
          */
         fchmodat_nofollow_unsupported =
-                         result && (errno == ENOTSUP) && !follow_symlinks;
+                         result &&
+                         ((errno == ENOTSUP) || (errno == EOPNOTSUPP)) &&
+                         !follow_symlinks;
     }
     else
 #endif
-- 
cgit v0.12