with the fact that getgroups(2) might return
more that MAX_GROUPS on OSX.
See the issue (and python-dev archives) for the
gory details. Summarized: OSX behaves rather oddly
and Apple says this is intentional.
Added Windows support for os.symlink when run on Windows 6.0 or greater,
aka Vista. Previous Windows versions will raise NotImplementedError
when trying to symlink.
Includes numerous test updates and additions to test_os, including
a symlink_support module because of the fact that privilege escalation
is required in order to run the tests to ensure that the user is able
to create symlinks. By default, accounts do not have the required
privilege, so the escalation code will have to be exposed later (or
documented on how to do so). I'll be following up with that work next.
Note that the tests use ctypes, which was agreed on during the PyCon
language summit.
Create os.environb mapping and os.getenvb() function, os.unsetenv() encodes str
argument to the file system encoding with the surrogateescape error handler
(instead of utf8/strict) and accepts bytes, and posix.environ keys and values
are bytes.
svn+ssh://pythondev@svn.python.org/python/trunk
........
r80844 | victor.stinner | 2010-05-06 01:33:33 +0200 (jeu., 06 mai 2010) | 5 lines
Untabify Modules/posixmodule.c
Run Antoine Pitrou "untabify" script + manual editions (OS/2 and some
continuation lines).
........
r80845 | victor.stinner | 2010-05-06 02:03:44 +0200 (jeu., 06 mai 2010) | 4 lines
Untabify Modules/posixmodule.c (2)
Fix some more functions by hand
........
I rewrote the patch for py3k from scratch using untabify + manual editions
POSIX systems with a C extension module. This is required in order for
the subprocess module to be made thread safe.
The pure python implementation is retained so that it can continue to be
used if for some reason the _posixsubprocess extension module is not
available.
The unittest executes tests on both code paths to guarantee compatibility.
* Moves PyLong_FromPid and PyLong_AsPid from posixmodule.c into longobject.h.
Code reviewed by jeffrey.yasskin at http://codereview.appspot.com/223077/show
svn+ssh://pythondev@svn.python.org/python/trunk
........
r78531 | gregory.p.smith | 2010-02-28 18:31:33 -0800 (Sun, 28 Feb 2010) | 2 lines
Fix for r78527. It left out updating forkpty.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r78527 | gregory.p.smith | 2010-02-28 17:22:39 -0800 (Sun, 28 Feb 2010) | 4 lines
Issue #7242: On Solaris 9 and earlier calling os.fork() from within a
thread could raise an incorrect RuntimeError about not holding the import
lock. The import lock is now reinitialized after fork.
........
r78550 | gregory.p.smith | 2010-02-28 22:01:02 -0800 (Sun, 28 Feb 2010) | 2 lines
Fix test to be skipped on windows.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r78546 | gregory.p.smith | 2010-02-28 21:43:43 -0800 (Sun, 28 Feb 2010) | 3 lines
Fixes issue #7999: os.setreuid() and os.setregid() would refuse to accept
a -1 parameter on some platforms such as OS X.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r76636 | antoine.pitrou | 2009-12-02 21:37:54 +0100 (mer., 02 déc. 2009) | 5 lines
Issue #7333: The `posix` module gains an `initgroups()` function providing
access to the initgroups(3) C library call on Unix systems which implement
it. Patch by Jean-Paul Calderone.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r74841 | thomas.wouters | 2009-09-16 14:55:54 -0500 (Wed, 16 Sep 2009) | 23 lines
Fix issue #1590864, multiple threads and fork() can cause deadlocks, by
acquiring the import lock around fork() calls. This prevents other threads
from having that lock while the fork happens, and is the recommended way of
dealing with such issues. There are two other locks we care about, the GIL
and the Thread Local Storage lock. The GIL is obviously held when calling
Python functions like os.fork(), and the TLS lock is explicitly reallocated
instead, while also deleting now-orphaned TLS data.
This only fixes calls to os.fork(), not extension modules or embedding
programs calling C's fork() directly. Solving that requires a new set of API
functions, and possibly a rewrite of the Python/thread_*.c mess. Add a
warning explaining the problem to the documentation in the mean time.
This also changes behaviour a little on AIX. Before, AIX (but only AIX) was
getting the import lock reallocated, seemingly to avoid this very same
problem. This is not the right approach, because the import lock is a
re-entrant one, and reallocating would do the wrong thing when forking while
holding the import lock.
Will backport to 2.6, minus the tiny AIX behaviour change.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r72852 | antoine.pitrou | 2009-05-23 17:37:45 +0200 (sam., 23 mai 2009) | 5 lines
Issue #1983: Fix functions taking or returning a process identifier to use
the dedicated C type `pid_t` instead of a C `int`. Some platforms have
a process identifier type wider than the standard C integer type.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r72698 | hirokazu.yamamoto | 2009-05-17 11:52:09 +0900 | 1 line
Issue #3527: Removed Py_WIN_WIDE_FILENAMES which is not used any more.
........
r72699 | hirokazu.yamamoto | 2009-05-17 11:58:36 +0900 | 1 line
Added NEWS for r72698.
........
Broken Py3.1 release build in Visual Studio 2005
The CRT runtime structure that holds ioinfo doesn't appear to match the decleration from the headers provided with the Visual Studio 2005 crt sources. In Release, an extra 8 bytes follow the final BOOL. I cannot explain this, but the code works now, both in 32 bits and 64
Benjamin Peterson
Antoine Pitrou
Raymond Hettinger
Ronald Oussoren
Martin v. Löwis
Brian Curtin
Senthil Kumaran
Amaury Forgeot d'Arc
Victor Stinner
Mark Dickinson
Gregory P. Smith
Hirokazu Yamamoto
Eric Smith
Kristján Valur Jónsson