Richard Oudkerk added the comment: On 14/03/2013 1:00pm, Martin v. Löwis wrote: > That's why I was asking for an actual patch. The proposed change may > well not be implementable. If os.open continues to create CRT handles, > a way needs to be found to get a CRT handle that as the > FILE_SHARE_DELETE bit set.
The patch *does* create CRT fds from win32 handles by using msvcrt.open_osfhandle(). One other issue is that I do not know of a way to determine the current umask without temporarily changing it, causing a thread-race. In the end I am not sure it is worth the hassle. (But maybe it would be a good idea to add test.support.open() using FILE_SHARE_DELETE and test.support.unlink() to make the testsuite more resilient to "Permission Denied" errors.) > An alternative approach could be that os.open stops creating CRT > handles, and directly uses OS handles. The problem with that is that > stdin/stdout/stderr would stop being 0/1/2, which is not acceptable. > An alternative solution to that could be that we introduce a notion > of "python io handles", parallel, but indepedendent from CRT handles. > And so on. http://bugs.python.org/issue12939 has C implementations of _io.WinFileIO and _io.openhandle() which are equivalents for _io.FileIO and os.open() which use "native" Windows handles. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15244> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
