Add FileHandleType enum and SafeFileHandle.Type property

[Copilot]

Description

Adds System.IO.FileHandleType enum and SafeFileHandle.Type property for efficient runtime detection of file handle types. POC implementation to validate API feasibility before formal proposal (issue #122806).

Changes

API Surface

• System.IO.FileHandleType enum: 8 values (Unknown, RegularFile, Pipe, Socket, CharacterDevice, Directory, SymbolicLink, BlockDevice). All values supported cross-platform; BlockDevice returns Unknown on Windows.

• SafeFileHandle.Type property: Returns cached FileHandleType. Throws ObjectDisposedException when closed. Single syscall per handle lifetime via volatile int _cachedFileType.

Implementation

Windows (SafeFileHandle.Windows.cs):

• GetFileTypeCore(): Maps GetFileType() result to enum values
• FILE_TYPE_PIPE: Calls GetNamedPipeInfo; success → Pipe, ERROR_PIPE_NOT_CONNECTED → Pipe, else → Socket
• FILE_TYPE_DISK: Queries attributes + reparse tag via GetFileInformationByHandleEx; only IO_REPARSE_TAG_SYMLINK → SymbolicLink, other reparse points → Unknown
• CanSeek: Now checks Type == RegularFile (excludes directories/symlinks, was FILE_TYPE_DISK)

Unix (SafeFileHandle.Unix.cs):

• GetFileTypeCore(): fstat + S_IFMT mode bit mapping
• Init(): Opportunistically caches type when fstat already performed (line 343)
• Exceptions include Path parameter for diagnostics

Interop:

• Interop.GetNamedPipeInfo.cs: Parameter changed SafePipeHandle → SafeHandle (CoreLib cannot reference SafePipeHandle)
• Interop.FILE_ATTRIBUTE_TAG_INFO.cs: New struct + FileAttributeTagInfo constant for reparse tag queries
• Interop.GetFileType_SafeHandle.cs: Added to System.IO.Ports for downlevel multi-targeting

System.IO.Ports:

• SerialStream.Windows.cs: Uses Type property on NET11_0_OR_GREATER, falls back to GetFileType() on older targets

Example

using SafeFileHandle handle = File.OpenHandle("file.txt", FileMode.Open);
FileHandleType type = handle.Type;  // FileHandleType.RegularFile (cached)

using SafeFileHandle console = Console.OpenStandardInputHandle();
console.Type;  // FileHandleType.CharacterDevice

Notes

• All code review feedback addressed: error code handling, reparse tag checking, exception diagnostics, nullable annotations
• Comprehensive test coverage: 9,195 tests pass, 0 failures
• CanSeek behavior tightened on Windows (now excludes directories/symlinks)
• Multi-targeting in System.IO.Ports demonstrates backward compatibility pattern

---

💡 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.

[adamsitnik]

@copilot please address my feedback

[Copilot]

@copilot please address my feedback

All feedback has been addressed in commit 9edcc96.

[adamsitnik]

@copilot address my feedback

[Copilot]

@copilot address my feedback

All feedback addressed in commit 1f0655f.

[adamsitnik]

@copilot please address my feedback

[Copilot]

@copilot please address my feedback

All feedback addressed in commit 8994464.

[adamsitnik]

⚠️ CanSeek Behavior Change
Changed from FILE_TYPE_DISK (includes dirs/symlinks) to RegularFile (excludes them). Semantically correct but is a behavioral change. Verify ~46 callsites handle this.

@adamsitnik what can you tell me about this? Is it correct or incorrect, and if correct, is this expected?

So far, CanSeek was returning true for file, directories and symlinks. But we don't allow opening directories with our File APIs (as handles) and even if we did, it's not possible to read from directory using File/FileStream/RandomAccess APIs. For symlinks, we always resolve the symlinks and all our APIs for reading file content deal with the resolved file rather than symlink.

[adamsitnik]

@copilot please address my feedback