Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit dbbc0c8

Browse files
committed
Issue #14626: Fix buildbot issue on OpenIndiana 3.x machines. (Hopefully.)
1 parent fafd9ee commit dbbc0c8

2 files changed

Lines changed: 26 additions & 12 deletions

File tree

Lib/os.py

Lines changed: 21 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -179,16 +179,27 @@ def _add(str, fn):
179179

180180
_set = set()
181181
_add("HAVE_FACCESSAT", "access")
182-
# Current linux (kernel 3.2, glibc 2.15) doesn't support lchmod.
183-
# (The function exists, but it's a stub that always returns ENOSUP.)
184-
# Now, linux *does* have fchmodat, which says it can ignore
185-
# symbolic links. But that doesn't work either (also returns ENOSUP).
186-
# I'm guessing that if they fix fchmodat, they'll also add lchmod at
187-
# the same time. So, for now, assume that fchmodat doesn't support
188-
# follow_symlinks unless lchmod works.
189-
if ((sys.platform != "linux") or
190-
("HAVE_LCHMOD" in _have_functions)):
191-
_add("HAVE_FCHMODAT", "chmod")
182+
# Some platforms don't support lchmod(). Often the function exists
183+
# anyway, as a stub that always returns ENOSUP or perhaps EOPNOTSUPP.
184+
# (No, I don't know why that's a good design.) ./configure will detect
185+
# this and reject it--so HAVE_LCHMOD still won't be defined on such
186+
# platforms. This is Very Helpful.
187+
#
188+
# However, sometimes platforms without a working lchmod() *do* have
189+
# fchmodat(). (Examples: Linux kernel 3.2 with glibc 2.15,
190+
# OpenIndiana 3.x.) And fchmodat() has a flag that theoretically makes
191+
# it behave like lchmod(). So in theory it would be a suitable
192+
# replacement for lchmod(). But when lchmod() doesn't work, fchmodat()'s
193+
# flag doesn't work *either*. Sadly ./configure isn't sophisticated
194+
# enough to detect this condition--it only determines whether or not
195+
# fchmodat() minimally works.
196+
#
197+
# Therefore we simply ignore fchmodat() when deciding whether or not
198+
# os.chmod supports follow_symlinks. Just checking lchmod() is
199+
# sufficient. After all--if you have a working fchmodat(), your
200+
# lchmod() almost certainly works too.
201+
#
202+
# _add("HAVE_FCHMODAT", "chmod")
192203
_add("HAVE_FCHOWNAT", "chown")
193204
_add("HAVE_FSTATAT", "stat")
194205
_add("HAVE_LCHFLAGS", "chflags")

Modules/posixmodule.c

Lines changed: 5 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2696,7 +2696,8 @@ posix_chmod(PyObject *self, PyObject *args, PyObject *kwargs)
26962696
/*
26972697
* fchmodat() doesn't currently support AT_SYMLINK_NOFOLLOW!
26982698
* The documentation specifically shows how to use it,
2699-
* and then says it isn't implemented yet. (glibc 2.15)
2699+
* and then says it isn't implemented yet.
2700+
* (true on linux with glibc 2.15, and openindiana 3.x)
27002701
*
27012702
* Once it is supported, os.chmod will automatically
27022703
* support dir_fd and follow_symlinks=False. (Hopefully.)
@@ -2709,7 +2710,9 @@ posix_chmod(PyObject *self, PyObject *args, PyObject *kwargs)
27092710
* and we can't do that in this nested scope. (Macro trickery, sigh.)
27102711
*/
27112712
fchmodat_nofollow_unsupported =
2712-
result && (errno == ENOTSUP) && !follow_symlinks;
2713+
result &&
2714+
((errno == ENOTSUP) || (errno == EOPNOTSUPP)) &&
2715+
!follow_symlinks;
27132716
}
27142717
else
27152718
#endif

0 commit comments

Comments
 (0)