[ElectLive]

Problem

TruePath/Kernel32.cs hand-rolls Win32 interop constants, and two of them do not match the Windows headers (#241):

• FileShare.Delete was 0x03 鈥?that is Read | Write; FILE_SHARE_DELETE is 0x04.
• FileAttributes.PosixSemantics was 0x0100000 (one digit short) 鈥?it collides with OpenNoRecall; FILE_FLAG_POSIX_SEMANTICS is 0x01000000.

Both members are dead code today, but the wrong values are a trap for whoever uses them first: CreateFile would silently get a different sharing/behavior combination than the name suggests.

The maintainer's call on the issue was broader than fixing the two numbers: "A huge portion of the Kernel32 type (including but not limited to the mentioned flags) is completely unused 鈥?let's clean it up and drop all the unused constants/flags."

What this PR does

• Dropped every declaration in Kernel32 that nothing in the codebase references 鈥?156 lines removed. That includes both wrong-valued members listed above, so the trap is gone along with the dead weight. What remains is exactly what DiskUtils.cs uses: the GetFinalPathNameByHandle / CreateFile / DeviceIoControl P/Invokes, the FSCTL_GET_REPARSE_POINT, MAXIMUM_REPARSE_DATA_BUFFER_SIZE and IO_REPARSE_TAG_MOUNT_POINT constants, the SymbolicLinkReparseBuffer struct, and the enum members actually passed to CreateFile (BackupSemantics, OpenReparsePoint, ReadEa, ReadAttributes, Read).
• Kept values double-checked against the Windows headers (winnt.h, winioctl.h).
• Added Kernel32ConstantsTests (5 tests) pinning the surviving constant values and the reparse-buffer size to the header values, so a future typo in one of these numbers fails the build instead of waiting for someone to hit it at runtime.
• CHANGELOG entry under Unreleased 鈫?Changed.

Verification

Commands run locally on Windows (net8.0|x64), .NET SDK 10.0.402, from the repo root. Baseline (master @ 682b3256, before my change):

$ dotnet build
Build succeeded.    0 Error(s)

$ dotnet test
Test summary: failed!
  Total:   470
  Failed:    2
  Success: 468

The 2 baseline failures are AbsolutePathTests.ReadKind_IsSymlink / OnWindows_ReadKind_IsJunction 鈥?Directory.CreateSymbolicLink throws UnauthorizedAccessException in a non-elevated shell, exactly the environment limitation CONTRIBUTING.md warns about; they are unrelated to this change.

After the change:

$ dotnet build
Build succeeded.    0 Error(s)

$ dotnet build -p:CheckXmlDoc=true --no-incremental
Build succeeded.    0 Error(s)   # same flag as the xml-doc CI job, no CS15xx warnings

$ dotnet test
Test summary: failed!
  Total:   475
  Failed:    2
  Success: 473

$ dotnet test --filter "FullyQualifiedName~DiskUtilsTests|FullyQualifiedName~Kernel32ConstantsTests"
Test summary: passed!
  Total:   7
  Success:   7

Same 2 pre-existing symlink-permission failures as the baseline, nothing new; the 5 added tests pass, and the DiskUtils tests that actually exercise the surviving CreateFile / GetFinalPathNameByHandle / DeviceIoControl paths still pass.

scripts/Test-Encoding.ps1 (the encoding CI gate) also passes: no UTF-8 BOM, LF endings.

Closes #241

[ForNeVeR]

Thanks! I decided to migrate to CsWin32 in the end of this commit chain, thus eliminating the problem at hand.