classification
Title: On windows, "import nul" always succeed
Type: Stage: resolved
Components: Windows Versions: Python 2.7
process
Status: closed Resolution: works for me
Dependencies: Superseder:
Assigned To: tim.golden Nosy List: amaury.forgeotdarc, eric.araujo, georg.brandl, markm, ocean-city, terry.reedy, tim.golden
Priority: low Keywords:

Created on 2008-06-13 01:18 by amaury.forgeotdarc, last changed 2013-07-31 15:09 by tim.golden. This issue is now closed.

Messages (12)
msg68115 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-06-13 01:18
on Windows, the stat() function always returns True for some special
device names (nul, con, com1, lpt1...), even when followed by an extension.

Thus "import con" manages to find that "con.py" exists, and tries to
read from it... fun.

A solution is to use GetFileAttributes() instead.

Note that on python2.5.2, the error message suggest that we have such a
problem, but fortunately the error is still an ImportError::
  >>> import nul
  ImportError: DLL load failed: Le module spécifié est introuvable.
msg68163 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-06-13 14:40
The title is misleading -- if what you show is correct then "import nul"
doesn't succeed :)
msg68164 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-06-13 14:55
Sorry, I was not clear.
With python 2.5.2, "import nul" correctly raises ImportError, even if
the error message is slightly misleading.

With a recent release25-maint (and all other branches), "import nul"
does succeed, and creates an empty module. 
"import con" seems to block, it actually waits for the user to enter
text and type ^Z. Then it prints to the console some bizarre text that
looks like the content of a .pyc file:

Python 2.5.3a0 (release25-maint, Jun 11 2008, 13:17:36) [MSC v.1200 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import con
^Z
a=1
b=2
c=3
^Z
│≥
    c        ☺   @   s►   d  Z  d☺ Z☺ d☻ S(♥   i☻   i♥   N(☻   t☺   bt☺
  c(    (    (    s♠   con.py   <module>☺   s☻   ♠☺    [27520 refs]
>>> dir(con)
['__builtins__', '__doc__', '__file__', '__name__', 'b', 'c']
[27533 refs]
msg68169 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-06-13 15:14
I was wrong. It seems that an installed python works correctly, but a
python running from its build directory has the problem.
msg68170 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-06-13 16:43
OK, I think I got is now. The difference is between debug and release
builds.

Explanation:
- in release build, "import nul" calls stat("nul.pyd") which succeeds.
It then tries LoadLibrary("nul.pyd"), which fails with a DLL error.
- in debug builds, "import nul" first tries stat("nul_d.pyd") which
fails. It then tries stat("nul.py"), which succeeds to return an empty file!

Whaaaa.
msg69039 - (view) Author: Hirokazu Yamamoto (ocean-city) * (Python committer) Date: 2008-07-01 07:55
GetFileAttributes() succeeds for "nul", but GetFileAttributesEx() fails.
Maybe is it good idea to use GetFileAttributesEx()?

# test code

import ctypes
import ctypes.wintypes as type

dll = ctypes.windll.kernel32

print dll.GetFileAttributesA("nul") # 32

class WIN32_FILE_ATTRIBUTE_DATA(ctypes.Structure):
	_fields_ = [("dwFileAttributes", type.DWORD),
	            ("ftCreationTime", type.FILETIME),
	            ("ftLastAccessTime", type.FILETIME),
	            ("ftLastWriteTime", type.FILETIME),
	            ("nFileSizeHigh", type.DWORD),
	            ("nFileSizeLow", type.DWORD)]

GetFileExInfoStandard = 0

wfad = WIN32_FILE_ATTRIBUTE_DATA()

print dll.GetFileAttributesExA("nul", GetFileExInfoStandard,
ctypes.byref(wfad)) # 0
msg83451 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2009-03-11 02:17
Since I don't have access to Windows I am unassigning. Amaury, if this
is still a problem should we go ahead and switch to
GetFileAttributesEx()? Or just realize this is a problem for people
developing Python?
msg83468 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2009-03-11 13:41
It's a problem with debug builds on Windows.
Lowering priority. 

Also, it is likely that the new import library will correct the problem.
msg112924 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-08-04 23:37
>it is likely that the new import library will correct the problem.

Did it? 

With standard 3.1.2,
>>> import nul
...
ImportError: DLL load failed: The specified module could not be found.
>>> import con
...
ImportError: No module named con

So is there any problem with 2.7, or should we close this?
msg112927 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-08-04 23:43
3.1 does not use importlib for imports.
msg137135 - (view) Author: Mark Mc Mahon (markm) * Date: 2011-05-28 14:29
I am not sure that I fully understand the issue - but it seems that trunk still has this issue.
As stated by Amaury - this is on DEBUG builds only.

c:\>pcbuild\python_d.exe
Python 3.3a0 (default, May 28 2011, 20:22:11) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import nul
[60967 refs]
>>> import con
^Z
[60986 refs]

c:\>PCbuild\python.exe
Python 3.3a0 (default, May 28 2011, 20:25:13) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import nul
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: DLL load failed: The parameter is incorrect.
>>> import con
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: DLL load failed: The specified module could not be found.
>>>
msg194001 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2013-07-31 15:09
This one seems to have been fixed by the importlib rebuild. I haven't bothered to trace the code path, but certainly "import nul" returns the expected "ImportError: No module named 'nul'" in both Debug & Release builds.
History
Date User Action Args
2013-07-31 15:09:34tim.goldensetstatus: open -> closed
resolution: works for me
messages: + msg194001

stage: resolved
2013-01-25 19:09:58brett.cannonsetnosy: - brett.cannon
2011-05-28 14:29:49markmsetnosy: + markm
messages: + msg137135
2010-08-13 10:05:26tim.goldensetassignee: tim.golden

nosy: + tim.golden
2010-08-04 23:43:33eric.araujosetnosy: + eric.araujo
messages: + msg112927
2010-08-04 23:37:57terry.reedysetnosy: + terry.reedy

messages: + msg112924
versions: + Python 2.7, - Python 2.6, Python 2.5, Python 3.0
2009-03-11 13:41:20amaury.forgeotdarcsetpriority: low

messages: + msg83468
2009-03-11 02:17:32brett.cannonsetassignee: brett.cannon -> (no value)
messages: + msg83451
2009-02-11 04:49:06ajaksu2setassignee: brett.cannon
nosy: + brett.cannon
2008-07-01 07:55:07ocean-citysetmessages: + msg69039
2008-06-13 16:43:16amaury.forgeotdarcsetmessages: + msg68170
2008-06-13 15:14:48amaury.forgeotdarcsetmessages: + msg68169
2008-06-13 14:55:05amaury.forgeotdarcsetmessages: + msg68164
2008-06-13 14:40:33georg.brandlsetnosy: + georg.brandl
messages: + msg68163
2008-06-13 01:18:47amaury.forgeotdarccreate