dotnet / dotnet/runtime

Long path support fails with Unicode characters even with LongPathsEnabled=1 in .NET on Windows

Open
#126,535 4 comments 0 reactions 0 assignees View on GitHub
area-System.IO needs-further-triage
Dominant language
C#
Stars
18.3k
Forks
5.6k
PR merge metrics
PR metrics pending

Description

### Description

Even after enabling `LongPathsEnabled` in the Windows registry (set to 1 and system rebooted), .NET applications still fail to handle file paths that exceed the 260-character `MAX_PATH` limit and contain Unicode characters (Thai, Japanese, Russian, Greek, etc.).
Actual Behavior
- File operations throw `PathTooLongException` or `DirectoryNotFoundException`
- Drag-and-drop of such paths throws `HRESULT: 0x8007007A` (The data area passed to a system call is too small)
- Explorer.exe automatically redirects to default folders when path is too long
- .NET file APIs do not properly handle the `\\?\` prefix for long path bypass
Environment
- Windows 10/11 (latest version)
- .NET 6/7/8 (all versions affected)
- Reproduced in PCL 2(plain craft launcher)(a minecraft launcher) (C# .NET application) consistently

### Reproduction Steps

1. Enable long path support in Windows:
- Open `regedit` as administrator
- Navigate to `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem`
- Set `LongPathsEnabled` DWORD value to `1`
- Reboot the system
2. Create a test path longer than 260 characters with mixed Unicode characters:
C:\test\ภาษาไทยカタカナРусскийΑλφαβητα\1\2\3\4\5\6\7\8\9\0\1\2\3\4\5\6\7\8\9\0\test.txt
3. Use .NET `File.ReadAllText()` or `Directory.GetFiles()` to access the path
4. Observe the exception/error
Expected Behavior
.NET should fully support long paths with Unicode characters when `LongPathsEnabled` is enabled, consistent with native Windows system behavior. The same path works correctly in PowerShell and native Win32 applications, confirming it's a .NET-specific bug.

### Expected behavior

.NET should fully support long paths with Unicode characters when `LongPathsEnabled` is enabled, consistent with native Windows system behavior.
The same path works correctly in PowerShell and native Win32 applications, confirming it's a .NET-specific bug.

### Actual behavior

- File operations throw `PathTooLongException` or `DirectoryNotFoundException` when accessing paths longer than 260 characters with Unicode characters
- Drag-and-drop of such paths throws `HRESULT: 0x8007007A` (The data area passed to a system call is too small)
- Explorer.exe automatically redirects to default folders when path is too long, even with `LongPathsEnabled` enabled
- .NET file APIs do not properly handle the `\\?\` prefix for long path bypass

### Regression?

_No response_

### Known Workarounds

_No response_

### Configuration

_No response_

### Other information

_No response_

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.