none
Regression calling _wstat64i32 on symlink directory with KB2467174 installed RRS feed

  • Question

  • In tracking down a bug in Python, I found that the problem is triggered by what appears to be a regression in the C runtime (msvcr90), specifically stat64.c. Apparently released as part of the changes for KB2467174, but also included with Win 7 SP1, this change seems to cause _wstat64i32 to return -1 when called on a symlink directory. With the older C runtime, the same call to _wstat64i32 succeeds with a result of 0. This is apparently because the later verslion of _wstat64i32 calls _wsopen_s on symlink directories, but the earlier version did not.

    To reproduce the problem, install Python (or IronPython) on Windows 64-bit, and then run the following .cmd file:

    @echo off
    mklink /d sample c:\windows
    set PYTHON=C:\Program Files (x86)\IronPython\ipy.exe
    :: 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
    

    Note that I used Python in the repro script simply because I don't know how to make calls into C libraries with any built-in scripting language. One could just as well reproduce the problem with a C program that calls _wstat64i32.

    I suspect the problem exists on 32-bit platforms as well, but I've been conducting my testing in 64-bit environments.

    I'm looking for someone to confirm that it's valid to call _wstat64i32 on a symlink directory and to devise a solution for getting the "stat" result for a symlinked directory in Windows.

    Thursday, May 19, 2011 7:48 PM

Answers

  • >Note that I used Python in the repro script simply because I don't know how to make calls into C libraries with any built-in scripting language. One could just as well reproduce the problem with a C program that calls _wstat64i32.

    Since its a regressions, can I suggest that you submit a bug report on
    the MS connect site: https://connect.microsoft.com/VisualStudio

    A simple C/C++ console project that demonstrates the issue may be the
    most direct example to use.

    Post a link to your bug report back here if you would please.

    Dave

    Friday, May 20, 2011 9:44 AM

All replies

  • >Note that I used Python in the repro script simply because I don't know how to make calls into C libraries with any built-in scripting language. One could just as well reproduce the problem with a C program that calls _wstat64i32.

    Since its a regressions, can I suggest that you submit a bug report on
    the MS connect site: https://connect.microsoft.com/VisualStudio

    A simple C/C++ console project that demonstrates the issue may be the
    most direct example to use.

    Post a link to your bug report back here if you would please.

    Dave

    Friday, May 20, 2011 9:44 AM
  • Friday, May 20, 2011 1:23 PM
  • Using my MSDN account, I've filed a support incident with Microsoft Support.
    Monday, January 9, 2012 11:26 PM
  • I've updated the MS Connect report with the following:

    I contacted Microsoft Support. The support technician helped me reach the Development team. The support technician relayed to me that the bug has been fixed in the main line of development and will be released with the next release of Visual Studio. This means the fix is not being back-ported to Visual Studio 2008, 2010, or their runtime libraries. In other words, this bug is going to remain around for a very long time.

    The workaround is to use the Windows APIs and not wstat for acquiring file and directory information.

    They did indicate that they would consider backporting the fix if there was demonstrable business impact. As they currently see it, there is very little business impact, so this issue is very low priority.

    Sunday, January 22, 2012 1:47 PM