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 returnFILE_DEVICE_DISK (e.g. sampleFAT32 source code) orFILE_DEVICE_CD_ROM (e.g. sampleCDFS source code).FILE_DEVICE_DFS is the distributed filesystem that combines multiple shares. A RAM disk device can useFILE_DEVICE_VIRTUAL_DISK, like the old RAM disk sample driver did, and the driver could implement a custom filesystem, but nowadays generallyFILE_DEVICE_DISK orFILE_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, andFILE_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), butFILE_DEVICE_NETWORK_FILE_SYSTEM isn't handled at all becauseGetFileType() returnsFILE_TYPE_UNKNOWN. I don't think these low-level devices fit into the POSIX regime ofS_IFCHR vsS_IFBLK, but they're more likeS_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 theFILE_DEVICE_NAMED_PIPE device type, but in my tests NPFS doesn't implementFileStatInformation. 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 mirrorsGetFileType, so it should be the same as our existing code.

Other than leading people the wrong way when they read our code, is there anythingwrong 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 inGetFileInformationByName(). I wouldn't want a device to be reported as a regular file instead of eitherS_IFCHR orS_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 thinkFILE_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 thatFileAttributes is set toFILE_ATTRIBUTE_NORMAL for a file that has no other attributes set. That's already required forFileBasicInformation, according to[MS-FSA]. Devices would be distinguished by havingFileAttributes set to 0.