Home Original page

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

"Martin v. Löwis" martin at v.loewis.de
Wed Nov 7 10:00:36 CET 2007 
> 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.

No. We want to phase out usage of the standard C library wherever we
can. Duplicating its logic is fine.

Also, I don't think Python should implement its own logic of what
a valid file name is - the approach of using strpbrk is flawed. IIRC,
some version of the CRT (or some other C library) used
GetFileAttributes to determine whether a file name is valid.

> 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.

Sure, but I really dislike the string parsing that the CRT does (and
I don't want to go back to using the CRT for stat-like calls).

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