os.stat returns incorrect a/c/mtime for files without permissions under Windows in Python 3.12

[kfrydel]

Bug report

Bug description:

We are switching our product to Python 3.12 from Python 3.11.2 and our tests caught a difference in the way os.stat works under Windows. It returns negative values of st_atime, st_mtime, and st_ctime if there are no permissions assigned to the file.

How to reproduce: you can remove all permissions using Windows Explorer, right-click on a file, select "Properties", select "Security" tab, press "Edit" button, and finally remove all entries from the "Group and user names" list. Or remove all inherited permissions in "Properties / Security /Advanced" window, icacls should show an empty list of permissions, for example:

PS C:\...> icacls a.txt
a.txt
Successfully processed 1 files; Failed processing 0 files

and then check the output in Python 3.12:

(python-312) PS C:\...> python -c "import os; print(os.stat('a.txt'))"
os.stat_result(st_mode=33206, st_ino=0, st_dev=0, st_nlink=0, st_uid=0, st_gid=0, st_size=0, st_atime=-11644473600, st_mtime=-11644473600, st_ctime=-11644473600)

and the same for Python 3.11.2, which is correct:

(python-311) PS C:\...> python -c "import os; print(os.stat('a.txt'))"
os.stat_result(st_mode=33206, st_ino=0, st_dev=0, st_nlink=0, st_uid=0, st_gid=0, st_size=0, st_atime=1699527432, st_mtime=1699527008, st_ctime=1699527008)

The returned value sounds like secs_between_epochs from https://github.com/python/cpython/blob/main/Python/fileutils.c#L1050 Maybe it has something to do with the issue.

CPython versions tested on:

3.12

Operating systems tested on:

Windows

Linked PRs

• gh-111877: Fixes stat() handling for inaccessible files on Windows #113716
• [3.12] gh-111877: Fixes stat() handling for inaccessible files on Windows (GH-113716) #113989
• gh-114096: Restore privileges in _winapi.CreateJunction #114089

[zooba]

As a quick reaction, it sounds like we're now successfully querying the file for attributes directly but not getting times, whereas before we were failing and falling back on the directory metadata.

@kfrydel Can you confirm the exact build number of the version of Windows you are using? The very latest releases (i.e. this month) have a new API that we will use when available (on account of it being much faster than the old one), so we'll likely need to know the build number to diagnose reliably.

[kfrydel]

I reproduce it on:
Edition: Windows 10 Enterprise
Version: 21H2
OS build: 19044.3570
Experience: Windows Feature Experience Pack 1000.19052.1000.0
(based on the About screen in Windows settings)

[zooba]

Okay, so definitely the old API. Possibly there's some logic that's changed to do with the fallback to FindFirstFile. I can't promise to look at it in the next few weeks, but hopefully someone can.

[gozdal]

The very latest releases (i.e. this month) have a new API that we will use when available (on account of it being much faster than the old one)

@zooba what is the new API?

[zooba]

The new API is GetFileInformationByName, which doesn't appear to have public documentation yet. It's essentially GetFileInformationByHandle but doesn't require the file to be opened. You won't get it on Windows 10 though, it'll only be available on Win11 AFAIK.