◐ Shell
reader mode source ↗
Skip to content

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

Closed
ntninja wants to merge 7 commits into
python:mainfrom
ntninja:fix-issue-39533
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
python:mainfrom
ntninja:fix-issue-39533

Conversation

@ntninja

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

Copy link
Copy Markdown

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

ghost commented Sep 12, 2022 •
edited by ghost
Loading

Copy link
Copy Markdown

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
Merged
@jbosboom jbosboom mentioned this pull request Jul 6, 2025
Closed
@cmaloney

cmaloney commented Aug 30, 2025

Copy link
Copy Markdown
Contributor

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

gpshead commented Aug 31, 2025 •
edited
Loading

Copy link
Copy Markdown
Member

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 Aug 31, 2025
@vstinner

vstinner commented Oct 21, 2025

Copy link
Copy Markdown
Member

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

vstinner commented Oct 21, 2025

Copy link
Copy Markdown
Member

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