Python 2.7 has no knowledge of directory symlinks on Windows 7. Listing a directory symlink does not work, nor does accessing a file within one. This is quite a notable missing feature on Windows 7, where symlinks are becoming increasingly prevalent.

Python 2.7 is not aware of symlinks and treats them like their targets, so it should be able to list a symlink directory or access a file within one. For example:

PS C:\Users\jaraco> cmd /c dir
 Volume in drive C is system
 Volume Serial Number is 2455-92A0

 Directory of C:\Users\jaraco

11-Nov-2011  06:50    <DIR>          .
11-Nov-2011  06:50    <DIR>          ..
..
11-Aug-2011  10:11    <SYMLINKD>     bin [Dropbox\bin\x64]
10-Aug-2011  21:00    <SYMLINKD>     bin-x86 [Dropbox\bin\x86]
..
              11 File(s)          6,632 bytes
              27 Dir(s)  301,972,422,656 bytes free
PS C:\Users\jaraco> python
Python 2.7.2 (default, Jun 12 2011, 14:24:46) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.listdir('bin')
['curl.exe', 'devcon.exe', 'HotSwap!.EXE', 'Notepad2.exe', 'utorrent.exe', 'vncviewer.exe']
>>> with open('bin/curl.exe', 'rb') as f:
...   f.read()[:10]
...
'MZ\x90\x00\x03\x00\x00\x00\x04\x00'
>>> ^Z

Because Python 2.7 is feature-frozen, symlink support will not be available in Python before 3.2.

If you are experiencing errors, please reopen this ticket and describe what you are doing, what you expect, and what you get instead.

What are you running? This is not what I get on Win7 x64, and I have had several other users in ##python on FreeNode confirm this inability. As far as Python is concerned, these dir sym links do not even exist.

I think we could still make os.listdir work properly. I'll look into a patch for this.

One "problem" here is the testability, since we'd need to rely on the mklink CLI app to create the symlinks, which requires that the calling application (python.exe) has elevated privileges. It wont be exercised by any of the buildbots.

I should mention that there is third-party symlink support in jaraco.windows (http://pypi.python.org/pypi/jaraco.windows). Just easy_install it, and then use jaraco.windows.filesystem.symlink.

If there are features you need for symlink support in jaraco.windows, request them via https://bitbucket.org/jaraco/jaraco.windows and they should be implemented quickly.

Thanks Bryan, that would be great.

The elevated privs problem could potentially be avoided by creating symlinks using the Win32 API directly. As long as the appropiate group policy is set, one does not require admin privs to create symlinks. Perhaps symlink creation/deletion on Windows could even be integrated into the Python class library?

Brian, I'm still not sure I see the problem with os.listdir. It includes symlinks when listing a dir and traverses them naturally when referencing them as part of a path to listdir. Under what conditions does it fail?

Well, at the very least it's a system-dependent issue, since I've tried out listdir and also file access on my system and some other Windows users'.

Some variables could be a missing privilege or role, or perhaps a UAC restriction. What error do you get when you attempt to invoke os.listdir on a symlink directory?

No error whatsoever. Python just thinks it doesn't exist unfortunately. Same report from other users...

symlinks when listing a dir and traverses them naturally when referencing
them as part of a path to listdir. Under what conditions does it fail?
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue13412>
> _______________________________________

Jason - I'm responding on a phone - I haven't confirmed anything yet (and
hadn't yet seen your examples when I was typing).

Alex - the Windows API also requires elevation - that's what we have to do
in 3.2+ as well. The symlink calls require a specific privilege which is
only granted when elevated, even for the mklink program.

When listing the parent dir in which a dir symlink resides, the dir symlink doesn't show up. That's the one I noticed most.

On Windows Vista and Windows 7, there should be a symlink directory:

C:\Documents and Settings -> .\Users

Perhaps a good test would be:

assert 'Documents and Settings' in os.listdir('C:\\')

As long as there aren't any i18n issues, and the system is a standard install, that test should only fail if os.listdir fails to return symlinks.

Okay, so I figured out where I was originally seeing this issue. (It does indeed work normally as you said; I'm not sure how I tested otherwise.)

Well, the problem is when you load a module that is a SYMLINKD. If the module folder is a normal directory, all works fine, otherwise it can't be found. Hopefully you can verify this.

I think this can then be considered a duplicate of issue #6727.

While this may in fact be related to #6727, I don't believe it's a proper duplicate. I believe there's a more fundamental issue that's causing both #6727 and #13412, and that's that stat/wstat is broken on Windows due to a regression in the MS C runtime: http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/93ebb061-d952-4650-b15c-30548a6649a8/

I mention that here because a fix for #6727 if localized to import.c may not address this issue.