gh-99726: Adds os.statx function and associated constants by zooba · Pull Request #99755 · python/cpython (original) (raw)

From my earlier comment, we shouldn't arrive in _Py_stat_basic_info_to_stat() for device types that don't implement a filesystem or aren't mounted by a filesystem. That's because, in my experience, FileBasicInformation (file attributes and timestamps) is only implemented for files and directories in a filesystem.

A filesystem type that mounts a volume will return FILE_DEVICE_DISK (e.g. sample FAT32 source code) or FILE_DEVICE_CD_ROM (e.g. sample CDFS source code). FILE_DEVICE_DFS is the distributed filesystem that combines multiple shares. A RAM disk device can use FILE_DEVICE_VIRTUAL_DISK, like the old RAM disk sample driver did, and the driver could implement a custom filesystem, but nowadays generally FILE_DEVICE_DISK or FILE_DEVICE_CD_ROM is used for a RAM disk (the ImDisk driver implements both).

FILE_DEVICE_DISK_FILE_SYSTEM, FILE_DEVICE_CD_ROM_FILE_SYSTEM, and FILE_DEVICE_NETWORK_FILE_SYSTEM are the device types for the base filesystem device, e.g. "\\?\GlobalRoot\FAT", "\\?\GlobalRoot\UdfsCdRom", or "\\?\UNC". os.stat() reports the first two as block devices (S_IFBLK), but FILE_DEVICE_NETWORK_FILE_SYSTEM isn't handled at all because GetFileType() returns FILE_TYPE_UNKNOWN. I don't think these low-level devices fit into the POSIX regime of S_IFCHR vs S_IFBLK, but they're more like S_IFCHR since reads and writes don't use a fixed block size. It's nearly a moot point since there's no useful reason to care. There isn't much to be done with such devices in user-mode applications.

In principle, the stat info classes could be implemented for the named-pipe filesystem on the FILE_DEVICE_NAMED_PIPE device type, but in my tests NPFS doesn't implement FileStatInformation. I asked whether it's planned to implement stat info classes in NPFS.