Skip to content

gh-83714: Use statx on more recent Linux to expose st_flags and st_btime on all platforms #19125

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
ntninja wants to merge 7 commits into from
Closed

gh-83714: Use statx on more recent Linux to expose st_flags and st_btime on all platforms #19125

ntninja wants to merge 7 commits into from

Conversation

@ntninja
Copy link

@ntninja ntninja commented Mar 23, 2020 •
edited by bedevere-app bot
Loading

Still missing tests, but I'd appreciate feedback on the changes themselves in the meantime. Also ideas for properly testing btime would be appreciated.

#83714

@ntninja ntninja force-pushed the fix-issue-39533 branch 4 times, most recently from 1c474bf to bd158bb Compare March 27, 2020 17:48
SebAlbert
SebAlbert reviewed Sep 5, 2022
View reviewed changes
@ghost
Copy link

ghost commented Sep 12, 2022 •
edited by ghost
Loading

All commit authors signed the Contributor License Agreement.
CLA signed

@alexander255 alexander255 mannequin mentioned this pull request Sep 12, 2022
Closed
@ntninja ntninja force-pushed the fix-issue-39533 branch 3 times, most recently from 667ece4 to 4d1edcc Compare September 13, 2022 00:44
@ntninja
Update file flag bits in the stat module and add the relevant Linux ones
4d82bc3
@ntninja
Always expose st_flags and st_btime{,_ns} on all platforms
e6bd28b 
On BSD/macOS this uses the value of `st_birthtime` (which remains for
compatibity reasons), on Windows it duplicates the value of `st_ctime`.

A Linux implementation is added in subsequent commits.
@ntninja
Add option to enable Linux statx in configure
c07edf2 
It cannot be enabled by default because this implementation does not have
any fallback to plain stat for older kernels and Linux 4.11 is still fairly
recent. The configure checks also ensure that the C library expose the
proper stub functions (glibc 2.28+ only).
@ntninja
Add statx-based stat implementation for Linux
54a23b5
@ntninja
Map Linux STATX_FLAG_* and Windows FILE_ATTRIBUTE_* flags to their BS…
53cee11 
…D UF_* equivalent as defined by FreeBSD
@ntninja
bpo-39533: Add documentation on new :func:os.stat properties
16775d0
@ntninja
Add support for STATX_ATTR_{VERITY,DAX} and the new stx_mnt_id field
9aae324
@martonivan martonivan mentioned this pull request Mar 6, 2024
Open
@jbosboom jbosboom mentioned this pull request Jul 6, 2025
Closed
ExplodingCabbage
ExplodingCabbage reviewed Aug 27, 2025
View reviewed changes
Misc/NEWS.d/next/Library/2020-03-23-18-21-49.bpo-32592.KvFMeC.rst
Use the ``statx(2)`` system call for :func:`os.stat` under Linux to provide
cross-platform support for btime (time of file creation) and file
attributes. On Windows btime is emulated using ctime and both Linux and
Windows file attributes are converted to their (Free)BSD equivalent were
Copy link

@ExplodingCabbage ExplodingCabbage Aug 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo - "were" should be "where"

gpshead
gpshead approved these changes Aug 30, 2025
View reviewed changes
Doc/library/stat.rst
STATX_ATTR_VERITY
STATX_ATTR_DAX

.. versionadded:: 3.12
Copy link
Member

@gpshead gpshead Aug 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tip - update version markers in docs to "next" and it'll automagically use the right version.

@cmaloney
Copy link
Contributor

cmaloney commented Aug 30, 2025

Could this be performance checked against the existing stat? Stat is called a lot (in Python 3.14 on linux once for every file opened which includes imports by default) and my worry is issues like https://lwn.net/Articles/944214/ where the different variants of stat have quite a bit of performance delta.

@gpshead
Copy link
Member

gpshead commented Aug 31, 2025 •
edited
Loading

Another take on this: How about not modifying os.stat behavior at all but instead introduce an os.statx API that uses the more modern system call when available and exposes its functionality - in particular the mask functionality so that people can call it and get only the specific data they want instead of a large everything-bagel os.stat result.

The os module is all about providing wrappers around the underlying platform APIs.
(edit: raised this question on the issue)

@gpshead gpshead changed the title bpo-39533: Use statx on more recent Linux to expose st_flags and st_btime on all platforms gh-83714: Use statx on more recent Linux to expose st_flags and st_btime on all platforms Aug 31, 2025
@vstinner
Copy link
Member

vstinner commented Oct 21, 2025

Another take on this: How about not modifying os.stat behavior at all but instead introduce an os.statx API that uses the more modern system call when available and exposes its functionality - in particular the mask functionality so that people can call it and get only the specific data they want instead of a large everything-bagel os.stat result.

os.statx() has been added. This PR is now outdated, I close it. There is a discussion on using os.statx() in pathlib.

@vstinner vstinner closed this Oct 21, 2025
@vstinner
Copy link
Member

vstinner commented Oct 21, 2025

Thanks @ntninja for your contribution even if it was taken as it is. Exposing new syscalls is non trivial, it takes time to decide how to expose it in Python.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@gpshead gpshead gpshead approved these changes

+2 more reviewers

@SebAlbert SebAlbert SebAlbert left review comments

@ExplodingCabbage ExplodingCabbage ExplodingCabbage left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

awaiting merge

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

9 participants

@ntninja @cmaloney @gpshead @vstinner @SebAlbert @ExplodingCabbage @the-knights-who-say-ni @ezio-melotti @bedevere-bot