[issue40238] os.stat() on Windows succeeds for nonexistent paths with trailing spaces

Eryk Sun report at bugs.python.org
Fri Apr 10 08:06:33 EDT 2020


Eryk Sun <eryksun at gmail.com> added the comment:

> While I agree that Windows is safe to transform paths as he wishes to, 
> the bug reported here is that os.stat/os.path.isdir behaves 
> differently than os.scandir. Can we make them behave the same?

os.listdir and os.scandir can be modified to behave like os.stat, but not the other way around. They differ because a "*.*" wildcard component is appended to the path that's passed to FindFirstFileW, and trailing spaces and dots only get stripped in the final path component. 

To implement this without hard-coding Windows filename rules, the path needs to be normalized via WINAPI GetFullPathNameW before appending the "*.*" component (or just "*"; the ".*" is superfluous) -- but only for normal paths, i.e. paths that do not begin with exactly "\\\\?\\". The functions that would need to be updated are _listdir_windows_no_opendir and os_scandir_impl in Modules/posixmodule.c.

Another option would be to rewrite listdir and scandir to use CreateFileW and GetFileInformationByHandleEx: FileIdBothDirectoryInfo [1]. This query provides two additional fields in comparison to the classic find data: ChangeTime (Unix st_ctime) and FileId (Unix st_ino). If the file is flagged as a reparse point in its attributes, then the reparse tag is set in the EaSize field of the directory info, since extended attributes can't be set on a reparse point; see [MS-FSCC] 2.4.17 [2].

[1]: https://docs.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-file_id_both_dir_info
[2]: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/1e144bff-c056-45aa-bd29-c13d214ee2ba

----------
resolution: not a bug -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40238>
_______________________________________


More information about the Python-bugs-list mailing list