Slashdot Mirror
Microsoft Removes 260-Character Path Length Limit In Windows 10 Redstone (softpedia.com)
An anonymous reader quotes a report from Softpedia: Windows 10 build 14352, a preview version of the upcoming Anniversary Update (also known as Redstone), comes with an eagerly awaited change that Microsoft hasn't yet announced publicly. The 260-character path length limit in Windows can be removed with the help of a new policy, thus allowing you to run operations with files regardless of their path or file name. While this new rule is not enabled by default, admins can turn it on by following these instructions. Launch the Registry Editor by clicking the Start menu and typing "regedit.exe," and then navigate to the following path: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy Objects\{48981759-12F2-42A6-A048-028B3973495F}Machine\System\CurrentControlSet\Policies. Look for an entry called "LongPathsEnabled," and if it does not exist, simply right-click Policies, select New DWORD (32-bit), name it "LongPathsEnabled" (without the quotes), enter value 1, and you're good to go. The description of the preview reads, "Enabling NTFS long paths will allow manifested win32 applications and Windows Store applications to access paths beyond the normal 260 char limit per node. Enabling this setting will cause the long paths to be accessible within the process." While the Windows 10 preview build 1452 has been made available last week, according to Windows Central, a Microsoft team member says that the company could released Windows 10 Mobile build 14352 for Insiders on Tuesday, May 31.
This isn't just something you can switch on without thought.
Windows' native programming has long had a "MAX_PATH" constant, which devs would use to create a char[MAX_PATH] to accept user input (i.e. from a save file dialog). If you suddenly start creating paths larger than this, you risk buffer overflows.
Even if your app is carefully written to avoid buffer overflows in this situation, it may simply refuse to read the file with a path too large. Devs have been able to break beyond MAX_PATH for a while by using UNC paths, but almost nobody uses them because you'll find random apps that won't know how to use a longer path.
I find it a bit weird that they haven't taken an approach similar to high DPI, where you can embed a manifest resource into your app that'll tell the OS it supports high DPI. While this would not solve random apps refusing to work with larger paths, this would at least prevent buffer overflows.
NTFS doesn't have a 260 character limit, it is 32k. The limitation is in windows itself and seems to be another one of those limits kept purely for backward compatibility where a shitton of apps can't handle long paths.
Because as stated in another thread, MS/W devs do `char path[MAX_PATH];` So if MS removes the limit most programs will stack overflow.
Slashdot, fix the reply notifications... You won't get away with it...
Not file names -- file PATHs longer than 260 characters.
As in:
"C:\Users\Fubar\Pictures\Vacation\2013\Hawaii\Dole Plantation\Silly Photo with Sister 023.jpg"
Obviously, that's under 260 characters, but if you try copying an entire user profile to another computer's desktop folder "C:\Users\Foo\Desktop\old profile", you get an even longer character path... and some people have very elaborate Documents folders for work and school projects that are many nested folders deep and lots of characters for descriptions.
I've hit the character limit more than once myself -- especially with MP3 files with full band and song titles in the name and a few project files, but I've hit it multiple times copying entire profiles to servers as backups before swapping out a machine.
The summary mentions that it will only be available to manifested applications, i.e. ones for which the developer has already indicated it can deal with longer paths. Given that protection, there is absolutely no need for additional protection via a registry key.
Prepend "\\?\" to the path to tell the standard API to ignore MAX_PATH. This is how Robocopy and many other tools work around the issue.
Area51 - We are watching...
I've seen paths that tried to be longer than 260 characters with archives off of Usenet. Some idiot will use the filename as a text message. When it gets extracted the path becomes some_stupidly_long_200_character_filename/some_stupidly_long_200_character_filename.ext. Since the path then becomes too long, extraction fails.
The above isn't really a legitimate filename. It's being abused. But for a legitimate example, a common way to organize a HTPC movie collection is the format \Movies\[first_letter]\Title\Title.mkv. So Finding Nemo for instance would be \Movies\F\Finding Nemo\Finding Nemo.mkv. If you have a very long movie title (for example) then you legitimately would have a path too long if you used the full movie name.
There are easier ways.
Use MKLINK to create a symbolic link deeper into the path so that Explorer can work with a shorter path.
If it is a network share use NET USE to map a drive letter deep into the share path.
Use SUBST do do the same for local file systems, that is to mount a folder deep in the file path as a logical drive.
From a command line (cmd.exe) you can address long file paths with "\\?\[Drive Letter]\%File or directory path%". most commands work, but some, like RENAME will have trouble because it interprets the '?' as a wildcard.
You've been able to have really long paths forever in Win32, simply by prepending ""\\?\" to the path, which tells the Win32 APIs to not futz around with the path and instead just ship it straight down to the file system. If the file system itself can handle it, you're fine. There will still be other limits imposed, typically about 32K overall limit and 255 for each 'component', which is what they like to call each subdirectory or file that composes the overall path.