GeezerVison

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.

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.

Ah, that's a very good point (which I missed). There were some tests that stopped failing with my change here though, so clearly something ends up in this path.

My switch basically mirrors GetFileType, so it should be the same as our existing code.

Other than leading people the wrong way when they read our code, is there anything wrong with checking all the values? There's already a ton of stuff that doesn't map well into POSIX (all the error codes, for example), and I'd prefer our approximations at least be consistent with themselves, even if they aren't meaningful.

Other than leading people the wrong way when they read our code, is there anything wrong with checking all the values?

For the stat info classes, they could decide to specially handle some devices in the I/O manager, or implement a fallback in GetFileInformationByName(). I wouldn't want a device to be reported as a regular file instead of either S_IFCHR or S_IFBLK. It shouldn't be a problem as long as they only support the stat info classes for filesystem files and directories -- not for volume devices, filesystem devices, or controllers. (I don't think FILE_DEVICE_DATALINK is used by anything.)

I'll update the cases that should handle devices, though it does seem that the current builds don't return stat information by name for \\?\GlobalRoot\NTFS at least, and it goes through the old function. That could always change though.

If they do end up supporting all devices for the stat info classes, it should be okay as long as they require that FileAttributes is set to FILE_ATTRIBUTE_NORMAL for a file that has no other attributes set. That's already required for FileBasicInformation, according to [MS-FSA]. Devices would be distinguished by having FileAttributes set to 0.