Microsoft Removes 260-Character Path Length Limit In Windows 10 Redstone (softpedia.com) 260
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.
"simply right click" (Score:4, Funny)
There's nothing simple about fucking around in the registry. Why can't Microsoft just do things correctly the first time?
Re:"simply right click" (Score:4, Interesting)
There's nothing simple about fucking around in the registry.
Really? If you have problem with the registry how do you cope with the file system with all its folders? Or even the nested comments of Slashdot? I think that you are making this out to be a much bigger problem than it really is.
Re: (Score:3, Insightful)
> Really? If you have problem with the registry how do you cope with the file system with all its folders?
I don't give them names like {48981759-12F2-42A6-A048-028B3973495F}, for starters.
Re:"simply right click" (Score:4, Interesting)
Anyone who feels comfortable changing a simple registry entry is almost guaranteed to be able to do this without issue. Anyone who isn't probably doesn't even know what this change even does in the first place.
Re: (Score:2)
If you have problem with the registry how do you cope with the file system with all its folders?
The problem with the registry isn't that it is hard to navigate a hierarchical database, but the way it is being used, apparently to deliberately obfuscate the way applications are configured. As a result, it has become an obscenely hideous structure - compare this to the traditional UNIX style of configuration, in simple text files requiring just a text editor and a manual telling you how to do (another thing that is very often absent in Windows). And even if the manual doesn't exist, you can often make re
Re: (Score:3)
tl/dr the idea behind the registry wa
Re: (Score:2)
Re: (Score:3)
There's nothing simple about fucking around in the registry.
Really? If you have problem with the registry how do you cope with the file system with all its folders? Or even the nested comments of Slashdot? I think that you are making this out to be a much bigger problem than it really is.
Yes, of course it's easy! That's why I added a desktop shortcut for every user that takes them right into the registry.
After all, it's as easy to use as Windows Explorer, and what could possibly go wrong....
Re: "simply right click" (Score:4, Insightful)
Why not just turn this on by default? If this breaks some kind of DOS convention, then it's likely only relevant to enterprise users running some legacy crap, and assuming they run Windows 10 at all, I highly doubt they're going to upgrade to this build any time soon anyways.
Re: (Score:3)
There's undoubtedly a lot of code out there that has:
#define MAX_PATH 260
wchar buffer[MAX_PATH];
And by "legacy crap", you presumably mean "every version of Windows, ever". Because this has been the rule for Windows unless you did some funky tricks with your paths ("\\?\D:\very long path"), which gives you paths up to 32K in length.
It's about time they did away with that limit. It's sort of rare, but you can occasionally run into path limits, especially with deeply nested computer-generated filenames, etc.
Re: (Score:3)
This will resolve a lot of pain in the npm ecosystem.
Re: (Score:3)
From TFA:
Re: "simply right click" (Score:4, Interesting)
Even if Windows hides paths longer than 260 from legacy apps... What, exactly, will Windows return for a call to GetCurrentDirectory(), when a legacy app runs from a path longer than that? What happens when the user tries to explicitly load or save a file from such a path (as in, paste the too-long path directly into the file dialog, which then tries to stuff it into a variable defined as 260 characters long)?
I can't see any way for this not to break a ton of legacy apps, in potentially dangerous ways, regardless of whether MS checks their manifest.
Re: (Score:2)
Re: "simply right click" (Score:4, Informative)
Re: (Score:2)
For some reason I keep on running into it with Workplace Health and Safety people who like to set policies of incredibly long directory names and filenames with punctuation in them - plus very deep nesting while repeating part of the name of the directory above. Having a *nix fileserver I can rename things for them when they fuck up
Re: (Score:2)
There's undoubtedly a lot of code out there that has:
#define MAX_PATH 260 wchar buffer[MAX_PATH];
Undoubtably because that's defined as such in the Windows.h header file for both VS and the GCC off-shoots. Microsoft has known for years that this was a problem, but they also acknowledged the pain that a change like this would cause for thousands of developers and even more so for the poor bastards like me who have to support end of life software where we can't simply make a change and then recompile the source code to fix this problem. I kind of wanted them to leave this one alone, but I guess they are d
Re: (Score:2)
DOS conventions can be broken, but what about earlier Windows versions accessing the drive via network share? Could create serious problems there.
Re: (Score:2)
Re: (Score:3)
Why not just turn this on by default? If this breaks some kind of DOS convention, then it's likely only relevant to enterprise users running some legacy crap, and assuming they run Windows 10 at all, I highly doubt they're going to upgrade to this build any time soon anyways.
Because it was not traditionally a registry setting but a compile time setting. Software has to be updated to use the new capabilities, and most software probably won't be as the majority of software dependent on this issue will have by now been upgraded to use the Win32 Unicode/Wide-String APIs that have the 32k byte limit instead of the 260 byte limit in the Win32 ASCIIZ/ASCII-String APIs (CreateFileW vs CreateFileA). And that's also assuming that a simple re-compile will do the trick; unfortunately most
Re: (Score:2)
https://technet.microsoft.com/... [microsoft.com]
Or just use the approved way.
There might not be a ADMX for it yet. There are a couple of GPO settings there are no proper templates for. Annoying as hell.
Finally (Score:5, Funny)
I can replace my Linux machine!
Re: (Score:2)
I'm guessing this innovation was partly in response to supporting WSL, so one can install Ubuntu on an ntfs filesystem.
Re:Finally (Score:5, Informative)
Re: (Score:2)
What sort of thing would you use >260 character paths for? I'm not questioning the need, I'm just looking for people with practical applications because it's interesting.
Re: (Score:2)
Re: (Score:3)
At work it happens all the bloody time. We have a very large file share, around 10 TB, of files generated when we do projects for our clients . Frequently our account execs will try to organize one of our larger client folders and end up nesting files and folders so deeply that the data becomes inaccessible. It's pretty easy to do when many documents are generated by mac users, who give zero fucks about file and folder name length.
Also, I will bet that if you fire up powershell and do a "get-childitem *
Re: (Score:2)
Re:Finally (Score:4, Informative)
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 [imdb.com]) then you legitimately would have a path too long if you used the full movie name.
Re: (Score:3)
I remember people trolling the network admins with very long path names. If you create a directory with a long name, and then paste another directory with a long name inside it then back on XP it couldn't be deleted via Explorer. You had to use a command prompt and the 8.3 name.
That was in the 2000s though, back in my day it involved putting "spaced" in DOS file names by typing alt-2-5-5. Or better still put the space at the end of the file name.
Re: (Score:3)
Re: (Score:3)
The limitation is also built into .NET for backwards compatibility. As a result, Powershell can't work with long file paths either. My understanding is that there are .NET libraries you can use to add the capability to your applications.
However, cmd.exe can access long paths. You can address UNC paths by using "\\?\[Drive letter]\[path to directory or file]". Most commands work. Rename is a notable exception because it interprets the '?' as a wild card.
Re:Finally (Score:5, Informative)
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.
Re: (Score:2)
The easy way to deal with this is to use subst command to assign the offending folder to a drive letter. You can then delete the files (now with a shorter path) from the virtual drive.
In the pwd of a command prompt or the address bar of an Explorer window, type "subst x: \". Then once the files are deleted, type "subst x: /d"
Re: (Score:2)
Re: (Score:2)
That's actually funny.
Whilst paths could theoretically be any length on UFS, there was (actually still is) a #define called PATH_MAX which practically every programmer used to allocate buffers to hold paths. According to Posix, the absolute largest this define can be is 256 [opengroup.org] (fortunately, Linux ignores this and goes for 4096).
I bet there is a lot of Unix code out there that breaks, possibly in subtle ways when paths exceed PATH_MAX characters.
Re: (Score:2)
Hmmm...I just checked IRIX 6.5.29, plus Solaris 10 and 11- it says 1024, but also defines POSIX_PATH_MAX to 255
Does that mean... (Score:5, Funny)
Re: (Score:2)
Re: (Score:2)
Re:Login is hard to understand (Score:5, Informative)
Re: (Score:2)
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.
You may mean buffer overflow here.
The declaration you've quoted would be resolved at compile time, not run time. So if MAX_PATH was 260 at compile time and then run on a system where the runtime behavior allowed for longer paths, I could certainly see a buffer overflow condition happening. But the program will only ever allocated 260 bytes off the stack in that case, so stack usage would remain the same.
And I assume if MAX_PATH were _UI64_MAX (or whatever) at compile time, the compiler would complain.
Re: (Score:2)
Re: (Score:2)
The might stack overflow, depending on how they are written they also might do other things. I bet there is a fair amount of strncpy(foo, bar, MAX_PATH); out there as well. Which could lead to strings that are not null terminated but also don't overwrite, the result probably being some kind of crash when foo is read, the other possibility is truncation. A Only the first 260 bytes of path get copied the result is some later action is taken on the partial path. Maybe that fails, maybe that results in a n
Re: (Score:2)
Re: (Score:2)
Re:Login is hard to understand (Score:4, Funny)
I misread that as MSJW devs, and now I'm really hoping that doesn't become a thing.
Their code would never run successfully:
- They'd consider it every program's right to call abort(); without being criticized.
- They could only use peer-to-peer architectures, as master / slave is oppressive.
- All branching logic would initially be floating-point -based, as Boolean logic is exclusionary and thus a micro-aggression against LGBTQ culture. However, it would later be decided that forcing branching logic was inherently judgmental, and thus all program instructions must have an equal chance to execute every processor clock tick.
The one upside is that their code would be meticulously designed to avoid race conditions. Sadly, it would also be subject to nearly constant deadlock.
Re: (Score:2)
Perhaps in a weird situation you might want to protect a badly coded application from the longer path length?
Due to the design of the Windows API, almost all applications are 'badly coded' in this respect.
There's a good reason it's not on by default (Score:5, Informative)
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.
Re:There's a good reason it's not on by default (Score:4, Informative)
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.
And in true old-school Slashdot fashion, I've apparently skipped over a paragraph in TFA. Using manifests is exactly what they've done.
Re: There's a good reason it's not on by default (Score:2)
Notably, windows file explorer never used to allow file operations on >260 filepaths.
There's no good reason it's not on by default (Score:5, Informative)
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.
Re: (Score:2)
Sure there is a need. Lots of work flows require multiple applications. You don't want someone creating a file with application A they wound be able to read with application B. That is the kind of thing users generally can't understand and tends to result in lots a helpdesk calls.
I can see why enterprises might want the option to turn this off.
Re: (Score:2)
Yet another reason to hate Java
Re: (Score:2)
there is a need. To avoid many many support calls (or calls to the helpdesk) with questions like "I just copied some files but Program X can't see them. WHAT DID YOU DO TO THEM?"
You do realize that problem already exists, right? Explorer has supported 32k pathnames since at least XP. Apparently the problem is not as common as you are suggesting.
Re: (Score:2)
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.
It appears Microsoft assumes that only shitty programmers write code for Windows. MAX_PATH is a compile-time constant (#define in windef.h). Even if you declare char my_path[MAX_PATH] variable (surely, you mean char my_path[MAX_PATH+1], right?), you wouldn't just pass it in into some other function expecting exactly MAX_PATH characters to be written into it, right? Surely, you'll also pass in MAX_PATH as the number of chars you are expecting to get, right? Something like strncpy( my_path, other_path, MAX_PA
Re: (Score:2)
Which could still leave you without a terminating null unless you were first careful to memset(my_path, NULL, MAX_PATH +1); right?
Its also not like truncating a path could not lead to any sort of undesirable side effects.
Re: (Score:2)
Thanks (Score:2, Interesting)
Re: (Score:2, Insightful)
But no thanks ; not using OSes that have registries.
Including systemd, which populates its hives like Win95 did, from MSDOS .INI files.
Re: (Score:2)
Re: (Score:2)
This is not an NTFS problem but an old API problem (Score:5, Interesting)
This is not an NTFS problem but an old API problem that programs should have stopped using years ago (decades, actually).
Programs like the NPM Nodejs package manager have had, until recently, horrifically long pathnames for no good reason. This fixes that for them.
Nearly any other program doesn't have this problem.
Good job, NPM developers, for forcing MSFT to update a very old API that you still insist on using.
Re: (Score:2)
Why are people excited about this? (Score:2)
I don't imagine there are many people who are just dying to have filenames longer than 260 characters.
Re: (Score:3)
path names, not file names. Its quite easy when a file is buried a few levels deep. Especially with symbolic links.
Re: (Score:2)
Oh. Whoops. Fair point.
Re:Why are people excited about this? (Score:5, Informative)
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.
Re: (Score:2)
Our company is involved in a project where the 260 char limit is a big problem. The git repository is essentially a copy of a portion of a Java content repository with quite a deep structure. If you tried to clone it into your documents directory on Windows, the 260 character limit was guaranteed to be hit unless your login name was something like "Bob".
Re: (Score:2)
It's driven me nuts for years. Things will randomly fail and I have to move folders up to a new root or shorten the name of folders along the path. The fact that some programmes haven't had a problem whilst others do has just compounded the problem.
Re: (Score:2)
Mercurial stores working copy metadata with filenames with capitals E_S_C_A_P_E_D_ W_I_T_H_ U_N_D_E_R_S_C_O_R_E_S_ - it's even worse, it can't even version control trees that the API can cope with.
Re: (Score:2)
This was quite a long time ago (first half of 2008), so my information is out of date. It does seem like the sort of thing that would have been fixed, though.
I was assessing version control systems for an internal project. Git was not ready to work properly on Windows, and hard for normal users, Hg had that bug, Subversion was too slow (12 minute checkout time for the trees concerned.)
Bazaar came out on top. It worked properly on Windows, was 3x faster than SVN on Windows (and moved up to being more like 6-
I hit this limit once in the Unix world (Score:2)
I was at a company which developed a large CRM application and I was the person who tarred up software updates to send to sites. A small part of the application was in Java, and the Java programmers were enamoured with class names which emphasized descriptiveness over brevity. We ended up with some files where path+filename exceeded 255 characters, and tar broke. My fix was to tell the programmers to shorten their damn file and directory names. (This was about 15 years ago, and it would have been Gnu tar. )
\\?\ Solved this... (Score:5, Informative)
Re: (Score:2)
Re: \\?\ Solved this... (Score:2)
Maybe they can now fix all the illegal characters (Score:2, Insightful)
Or use of <, >,
Or the other strange arbitrary rules, e.g. spaces allowed in names but a filename must have something other than spaces in it. There are many others.
But Linux also should probably not limit file paths to 4096, I'd have thought that might start to be an issue for people using a lot of Unicode.
Welcome to 1990 (Score:2)
Re: (Score:2)
NTFS isn't the problem. NTFS supports up to 32k character file paths as well as a number of characters that windows deems illegal. This is a problem with the Windows API's and .Net. I frequently work with long paths in windows (as dictated by necessity, not by choice) by addressing UNC paths at the command line, or by mapping drive letters or creating symbolic links deep into the directory tree.
Registry path in summary is wrong (Score:2)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies -or-
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
Credit goes to user foobar in the article's comment section.
260 bytes should be enough for every one (Score:2)
oh!
wait.
Paramteric had a clever solution! (Score:3)
They found the 8.3 file name format very confining. So they did a simple hack. They would construct the file/path name just as they would in unix. Then send it through a string processor that will insert a "\" after every 8th char and keep creating sub directories to get the file name they wanted! User will see humongous file names and path names.
Our company has been supporting 4K path names now, I remember setting MAXPATHLEN to be 1025 (remember to allocate space for the trailing null) back when joined the company decades ago.
How many years of using robocopy to delete? (Score:2)
Re: Dear Microsoft, (Score:5, Funny)
Dear Family IT guy,
Thank you for choosing Windows as your OS. While we understand your concerns, we don't give a fuck. We want your data and we're going to take it. If you were going to switch to another OS you would have done it after Windows 8, but you didn't, so bend over and take it. Take it! Squeal like a pig! Squeal you little shit!
Sincerely,
Microsoft Support
Re: (Score:2)
Re: (Score:2)
Microsoft managers train with the airlines.
Re: (Score:2)
I want to be excited about Windows 10 but I can't. Please, please, please give me an official option to turn off telemetry like the Enterprise version has. I'm also interested in the Long-term Servicing Branch.
Thanks, A home user and family IT guy.
Are you new at this? Just curious, because Microsoft hasn't been listening to their user base in years.
Oh, and the Enterprise version will be fixed soon with the next round of involuntary updates, so don't worry about being left out from those telemetry "features"...
Re: (Score:2, Funny)
I want to be excited about Windows 10 but I can't. Please, please, please give me an official option to turn off telemetry like the Enterprise version has.
So if you just want to disable telemetry, in registry key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection create a 32-bit DWORD called AllowTelemetry and set it to 0. Restart Windows for the changes to take effect.
Re: (Score:2)
I want to be excited about Windows 10 but I can't. Please, please, please give me an official option to turn off telemetry like the Enterprise version has.
So if you just want to disable telemetry, in registry key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection create a 32-bit DWORD called AllowTelemetry and set it to 0. Restart Windows for the changes to take effect.
If you're correct, that's great news. Could you please the reason you think that's a reliable approach?
Re: (Score:3)
This doesn't work on Home or Pro editions. It's equivalent to setting feedback/diagnostics to "Basic" which still enables a minimal amount of telemetry. (http://www.askvg.com/truth-behind-disallowing-telemetry-and-data-collection-trick-in-windows-10/)
Not that I don't think people who have a problem with small amounts of software telemetry aren't ridiculous as it's almost garaunteed that many other devices and software they use also have telemetry features (eg: video game consoles, phones, cars, etc)
Re: Unicode and \\? (Score:2)
The compatibility issue is likely exactly why it's limited to Win32 applications with a manifest [microsoft.com] and Metro apps.
Re: (Score:3, Interesting)
easy fix: just recompile.
closed-source software? well now you've identified your first problem. ;)
Re: (Score:3)
Re: (Score:2)
I have to agree in this case. If you need more than 260, you are probably doing something stupid, and the few cases where it's not stupid are overshadowed by the vast majority that are.
Re: (Score:3)
The really hilarious (after the things have been recovered) side of it is being able to write stuff with a long path but not being able to read it back later.
"I've got a meeting in five minutes and I've cop
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Keep laughing, how many system critical variables is systemd in charge of now?