@@ -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" )
0 commit comments