This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author jaraco
Recipients asvetlov, brian.curtin, jaraco, ncoghlan, santoso.wijaya, wkornewald
Date 2011-05-17.21:36:57
SpamBayes Score 9.691075e-05
Marked as misclassified No
Message-id <1305668218.55.0.407654153709.issue6727@psf.upfronthosting.co.za>
In-reply-to
Content
Digging deeper with the Visual Studio debugger, I discovered the following interesting outcome (run with cmd.exe):

    @echo off
    mklink /d sample sample-target
    mkdir sample-target
    echo "" > sample-target\__init__.py
    :: Before KB2467174, returns 0; after, returns -1
    python -c "import ctypes; buf = (ctypes.c_char*256)(); print(ctypes.windll.msvcr90._wstat64i32(u'sample', ctypes.byref(buf)))"
    :: Always returns 13
    python -c "import ctypes; fd = ctypes.c_int(-1); print(ctypes.windll.msvcrt._wsopen_s(ctypes.byref(fd), u'sample', 0, 0x40, 0))"
    rmdir sample
    rmdir /s /q sample-target

The call to _wstat64i32 is returning -1 with the patched CRT... but when I traced _wstat64i32 (on a machine with the patched CRT), it called _wsopen_s, which apparently always returns -1.

So my guess is that the patched CRT changed something about _wstat64i32 such that it doesn't defer to _wsopen_s. I'm going to see if I can get an early version of Visual Studio that I can trace where _wstat64i32 doesn't fail.
History
Date User Action Args
2011-05-17 21:36:58jaracosetrecipients: + jaraco, ncoghlan, brian.curtin, asvetlov, santoso.wijaya, wkornewald
2011-05-17 21:36:58jaracosetmessageid: <1305668218.55.0.407654153709.issue6727@psf.upfronthosting.co.za>
2011-05-17 21:36:58jaracolinkissue6727 messages
2011-05-17 21:36:57jaracocreate