3 ms·
Rather than some removing this limitation I'd settle for the ability to have file paths longer than 260 characters. Also, why 260?
by contravariant 5y ago
Rather than some removing this limitation I'd settle for the ability to have file paths longer than 260 characters.
Also, why 260?
- wvenable 5y ago[drive][:\][path][null] is 1+2+256+1 or 260.
- contravariant 5y agoAh I see, and presumably path can't be empty so you just need a byte to denote the length?
- int_19h 5y agoIt's null-terminated, so there are no length bytes. You can have paths exceeding 260 chars for a long time now. The problem is that the older Win32 APIs that deal with files have structs with TCHAR[MAX_PATH] field in them, so changing that length would be a binary breaking change for apps. So the new APIs allow for longer paths, but code has to be specifically written to take advantage of them. Some languages and frameworks - e.g. Node.js and Python - had that support for a while; others are still catching up.
- Tempest1981 5y agoNotably, explorer.exe doesn't deal well with longer paths. But yeah, WSL may be the driving force.
- deleted 5y ago[deleted]
- Lammy 5y agoYou don't have to do anything if you're on Windows 10 ver 1607 or later, have `HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled` DWORD=1, and your application manifest declares itself `longPathAware`. Or for older Windows versions you can use UNC paths and skip the fixed-size Unicode normalization buffer than introduces the `MAX_PATH` limitation: https://docs.microsoft.com/en-us/dotnet/standard/io/file-path-formats#skip-normalization https://docs.microsoft.com/en-us/dotnet/standard/io/file-pat...