Add missing filesystem magic numbers to UnixFileSystemTypes enum

[Copilot]

main PR

Description

DriveInfo.DriveType returns Unknown and DriveFormat returns empty string for various filesystems on Linux, including exfat.

The UnixFileSystemTypes enum was missing several filesystem magic numbers, so numeric filesystem type lookups failed. The GetDriveType switch already handled many of these filesystem strings correctly.

Changes:

• Added exfat = 0x2011BAB0 (originally reported issue)
• Added missing magic numbers for filesystems already in GetDriveType switch:
  • aafs (0x5A3C69F0) - AppArmor filesystem
  • btrfs_test (0x73727279) - Btrfs test filesystem
  • daxfs (0x64646178) - DAX filesystem
  • efivarfs (0xDE5E81E4) - EFI variables filesystem
  • hostfs (0x00C0FFEE) - User Mode Linux host filesystem
  • ibrix (0x013111A8) - IBM GPFS/IBRIX
  • nsfs (0x6E736673) - Namespace filesystem
  • prl_fs (0x7C7C6673) - Parallels filesystem
  • smackfs (0x43415D53) - Smack security module
  • snfs (0xBEEFDEAD) - StorNext filesystem
• Added new commonly-used filesystems with both magic number and DriveType entry:
  • bcachefs (0xCA451A4E) - Modern CoW filesystem in Linux 6.7+
  • binderfs (0x6C6F6F70) - Android Binder filesystem
  • erofs (0xE0F5E1E2) - Enhanced Read-Only FS, used in Android/containers
  • pidfs (0x50494446) - PID filesystem
  • rdtgroup (0x07655821) - Intel RDT resource groups
  • zonefs (0x5A4F4653) - Zoned block device filesystem
• Synced src/native/libs/System.Native/pal_io.c MapFileSystemNameToEnum function with the updated enum values

All magic numbers sourced from Linux kernel magic.h and GNU coreutils stat.c.

Excluded: Kernel-internal magic numbers that aren't user-visible filesystems (STACK_END_MAGIC, DMA_BUF_MAGIC, DEVMEM_MAGIC, SECRETMEM_MAGIC, GUEST_MEMFD_MAGIC).

Customer Impact

Users mounting various drives (exfat USB drives/SD cards, bcachefs volumes, erofs container images, etc.) cannot programmatically identify the drive type or filesystem format.

Regression

No. These have been missing since the respective filesystem kernel support was added.

Testing

• All 6 System.IO.FileSystem.DriveInfo tests pass
• DEBUG assertion in Interop.MountPoints.FormatInfo.cs validates enum/switch consistency

Risk

Low. Addition of well-documented magic numbers from authoritative sources (Linux kernel and coreutils). No behavioral change for other filesystems.

Package authoring no longer needed in .NET 9

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>DriveInfo.DriveType returns Unknown for exfat filesystems</issue_title>
<issue_description>### Description

When using DriveInfo to check the DriveType of an exfat filesystem, it returns unknown. Also the filesystem shows as blank.

Reproduction Steps

Create a file based filesystem for a quick test (likely need to sudo to mount the test.img)

dd if=/dev/zero of=test.img bs=1M count=1024
mkfs.exfat test.img
mount -o loop test.img /mnt/testing

DriveInfo d = new DriveInfo("/mnt/test");
Console.WriteLine("Drive {0}", d.Name);
Console.WriteLine("  Drive type: {0}", d.DriveType);
Console.WriteLine("  File system: {0}", d.DriveFormat);

Expected behavior

I think, something like this. Similar to exfat

Drive /mnt/test
  Drive type: Fixed
  File system: msdos

Actual behavior

Drive /mnt/test
  Drive type: Unknown
  File system: 

Regression?

No, seems to have been this way since exfat was added as a filesystem type

Known Workarounds

None

Configuration

.Net 9.0.105
Linux - Arch
x86_64
Might be specific to Linux, unable to try on Windows or Mac

Other information

The problem appears to be because of a missing entry in the UnixFileSystemTypes enum

https://github.com/dotnet/runtime/blob/main/src/libraries/Common/src/Interop/Unix/System.Native/Interop.UnixFileSystemTypes.cs

The FormatInfo uses this to look up the format/type, defaulting to Unknown / string.Empty when the entry is missing.

https://github.com/dotnet/runtime/blob/main/src/libraries/Common/src/Interop/Unix/System.Native/Interop.MountPoints.FormatInfo.cs#L61

The comments in UnixFileSystemTypes say it should kept inline with the statfs man page, only the stat coreutils added the exfat with it's corresponding magic number without updating the man page.

https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.32-109-ga5e0d8f387

</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes DriveInfo.DriveType returns Unknown for exfat filesystems #115962

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

[jkotas]

@copilot Could you please double-check that we are not missing support for any other filesystem magic numbers?

[Copilot]

Pull request overview

This PR fixes an issue where DriveInfo.DriveType returns Unknown and DriveFormat returns an empty string for exFAT filesystems on Linux. The fix adds the missing exFAT filesystem magic number (0x2011BAB0) to the UnixFileSystemTypes enum, enabling proper identification of exFAT drives commonly used on USB drives and SD cards.

Key changes:

• Added exfat = 0x2011BAB0 to the UnixFileSystemTypes enum in alphabetical order

[Copilot]

@copilot Could you please double-check that we are not missing support for any other filesystem magic numbers?

I've reviewed the Linux kernel magic.h and GNU coreutils stat.c against our enum. In commit 0494282, I added:

Missing magic numbers for filesystems already in GetDriveType:

• aafs (0x5A3C69F0), daxfs (0x64646178), efivarfs (0xDE5E81E4), hostfs (0x00C0FFEE), ibrix (0x013111A8), nsfs (0x6E736673), prl_fs (0x7C7C6673), snfs (0xBEEFDEAD)

New commonly-used filesystems (magic number + DriveType entry):

• bcachefs (0xCA451A4E) - Merged in Linux 6.7
• erofs (0xE0F5E1E2) - Used in Android/containers
• zonefs (0x5A4F4653) - Zoned block devices

Note: I intentionally skipped wslfs as it shares magic number 0x53464846 with rootfs (already in enum), and internal kernel filesystems like secretmem, dma_buf that aren't user-accessible.

[stephentoub]

@copilot, how are you deciding which values to include, or which version of the cited files were you looking at? I see values in https://raw.githubusercontent.com/torvalds/linux/refs/heads/master/include/uapi/linux/magic.h that aren't included.

[Copilot]

@copilot, how are you deciding which values to include, or which version of the cited files were you looking at? I see values in https://raw.githubusercontent.com/torvalds/linux/refs/heads/master/incl...

My criteria was to include user-accessible filesystems and exclude kernel-internal magic numbers. I was looking at the current master branch of magic.h.

In commit 66703f0, I added the remaining user-accessible filesystems I had missed:

• binderfs (0x6C6F6F70), btrfs_test (0x73727279), pidfs (0x50494446), rdtgroup (0x07655821), smackfs (0x43415D53)

I intentionally excluded these kernel-internal values that aren't user-visible mount points:

• STACK_END_MAGIC - Internal kernel stack marker
• DMA_BUF_MAGIC, DEVMEM_MAGIC, SECRETMEM_MAGIC, GUEST_MEMFD_MAGIC - Kernel memory management internals

[am11]

The list in src/native/libs/System.Native/pal_io.c should also be kept in sync.

[stephentoub]

The list in src/native/libs/System.Native/pal_io.c should also be kept in sync.

@copilot

[Copilot]

The list in src/native/libs/System.Native/pal_io.c should also be kept in sync.

@copilot

Done in commit 76316fa. I've added the missing filesystem magic numbers to MapFileSystemNameToEnum in pal_io.c to keep it in sync with the UnixFileSystemTypes enum.