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
[EMAIL PROTECTED]
[EMAIL PROTECTED]
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
