Long path support fails with Unicode characters even with LongPathsEnabled=1 in .NET on Windows
- 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
Assessment
This issue has not been assessed yet.