On Windows Vista 64-bit, when running Python 2.6.2 (32 or 64 bit) from a
network share, e.g. \\Server\Share\python26\python.exe,
importing Tkinter fails with "WindowsError: [Error 3] The system cannot
find the path specified". See session output below for traceback.

This is due to incomplete support for long UNC (UNCW) paths such as
\\?\UNC\Server\Share\File in FixTk.py. 

The attached patch solves this issue.

-Christoph


C:\>\\server\share\python26\python.exe
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from Tkinter import *
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "\\server\share\python26\lib\lib-tk\Tkinter.py", line 38, in <module>
    import FixTk
  File "\\server\share\python26\lib\lib-tk\FixTk.py", line 59, in <module>
    for name in os.listdir(prefix):
WindowsError: [Error 3] The system cannot find the path specified:
u'UNC\\server\\share\\Python26\\tcl\\*.*'

Confirmed here. Added a unit test.

This issue is also present in Python 2.7b2.

The svn trunk requires a slightly different patch (attached).

Any chance to get this fixed in 2.7? On Windows, the bug prevents some popular applications and packages, such as pymol and matplotlib, to be used when installed on network shares, as is common practice in computer labs.

Can somebody please explain how the test and the reported bug are related? The patch seems to deal with paths that have "UNC" in them; and the test seems not to.

Also, cgohlke, can you please provide complete, detailed instructions on how to reproduce this issue? How do I get python.exe into \\Server\Share in the first place? And why did you not map a network drive letter?

to reproduce: on Vista, start

\\%COMPUTERNAME%\c$\python26\python.exe -c "import Tkinter; print Tkinter"

In this case, the path returned by GetFinalPathNameByHandle starts with \\?\UNC\.

Btw, this bug is also present in Python 3.1, of course when using tkinter instead of Tkinter.

Here is how to reproduce the bug on your local system: Install python-2.7b2.msi into C:\Python27. Then open a command prompt with administrator privileges and start python.exe as follows:

\\%COMPUTERNAME%\C$\Python27\python.exe -c "from Tkinter import *"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "\\KLAPAUCIUS\C$\Python27\lib\lib-tk\Tkinter.py", line 38, in <module>
    import FixTk
  File "\\KLAPAUCIUS\C$\Python27\lib\lib-tk\FixTk.py", line 56, in <module>
    for name in os.listdir(prefix):
WindowsError: [Error 3] The system cannot find the path specified: 'UNC\\KLAPAUCIUS\\C$\\Python27\\tcl/*.*'



It does not matter whether the network share is mapped as a drive letter or not, the Tkinter import fails with the same WindowsError. Also mounted network drives do have problems with UAC.

A local Python installation can simply be copied to a network share and used from there from several other computers. All that eventually needs attention is the python*.dll, some scripts, and the MSVC runtime. I have deployed Python like this for years in several computer labs.

> The patch seems to deal with paths that have "UNC" in them; 
> and the test seems not to.

The UNCW path is a result of the call to ctypes.windll.kernel32.GetFinalPathNameByHandleW() in FixTk.py, which translates "\\Server\Share\File" paths to "\\?\UNC\Server\Share\File".

Simply removing the leading "\\?\" from the UNCW path, as it is done in Python 2.6.5 and 2.7b2 FixTk.py, results in an invalid "UNC\Server\Share\File" path. The proposed patch removes "UNC" and prepends a "\\", which gives a valid "\\Server\Share\File" path.

Thanks for the patch. Committed as r81701, r81702, r81703 and r81704.