A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2007-November/075128.html below:

[Python-Dev] Special file "nul" in Windows and os.stat

[Python-Dev] Special file "nul" in Windows and os.stat"Martin v. Löwis" martin at v.loewis.de
Tue Nov 6 21:56:06 CET 2007
>>From my reading of the CRT source code, _stat() uses FindFirstFile().
> This in turn appears to return a valid result on "nul" -
> win32api.FindFile, which is a thin wrapper round FindFirstFile etc,
> returns
> 
>>>> win32api.FindFiles("nul")
> [(32, <PyTime:01/01/1601 00:00:00>, <PyTime:01/01/1601 00:00:00>,
> <PyTime:01/01/1601 00:00:00>, 0L, 0L, 0L, 0L, 'nul
> ', '')]

Ok. I would still like to avoid calling FindFirstFile *first*, i.e.
"normally" use GetFileAttributesEx first, and only fall back to
FindFirstFile if that gives an error. Such fallback already occurs
if the GetFileAttributesEx error was ERROR_SHARING_VIOLATION.

So is there any good way to determine that the GetFileAttributesError
was caused by using a "reserved" file name. It seems that the error
is ERROR_INVALID_PARAMETER, but that would also be issued if you
have an otherwise-invalid file name (e.g. one including wild cards),
right?

> This is on my machine, using the Windows Server 2003 SP1 CRT source
> code. How consistent it is across versions, or anything else, I can't
> say :-(

Thanks, that helps already.

Regards,
Martin
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4