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