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