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

[Scott Dial]

Martin v. Löwis wrote:
>> In order to keep the higher accuracy timestamps for normal files and to
>> maintain the old behavior, my recommendation would be that the existing
>> implementation of win32_stat/win32_wstat be extended to use
>> FindFileFirst if GetFileAttributes* fails. I would be willing to do the
>> legwork for such a patch if everyone agrees this is the appropriate
>> solution.
> 
> That, in general, might be wrong. os.stat("*.txt") should fail, even
> though FindFirstFile will succeed when passed that string.
> 

Sorry, I meant to imply that we would guard FindFirstFile in the same 
manner that _stati64 and friends do already (using strpbrk/wcspbrk to 
search for "?*" in the path). At that point, you have essentially 
duplicated the CRT code with the added improvement of using 
GetFileAttributes* to retrieve the high-precision timestamps. So, I 
think my opinion has changed now to say: first, use GetFileAttributes*, 
and if that fails use _stati64/_wstati64.

> That was my primary motivation for not using FindFirstFile by default:
> it may succeed even if the string being passed does not denote a file
> name.

While I understand your reasoning, I thought we were letting the 
platform decide what are and are not files. This bug appeared because we 
are imposing our own notion of what a file is or is not, probably only 
by ignorance of the differences of GetFileAttribute* and FindFirstFile. 
So, my suggestion is basically a compromise of keeping higher precision 
timestamps for paths where GetFileAttribute* works and retaining the old 
behavior for all others.

> 
>> * As an aside, Martin, I find the argument that "hard-wiring is bad" to
>> be against what is actually occurring in the posixmodule. For that
>> matter, the S_IFEXEC flag is hardwired to path in (*.bat, *.cmd, *.exe,
>> *.com) despite the fact that the platform says it is really anything in
>> the list of os.getenv('PATHEXT'), but I suppose that is a bug for
>> another day.
> 
> No. See the source of the C library - the algorithm Python uses now is
> (or should be) the same as the one of the C library. Of course, you
> may argue that then msvcrt has the same bug.
> 

I concede and apologies, I didn't read the code for converting 
attributes to mode flags. I don't imagine (m)any people care about this 
flag on the win32 platform anyways.

-Scott

-- 
Scott Dial
scott at scottdial.com
scodial at cs.indiana.edu