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.

Comments

"simply right click"

[Anonymous Coward]

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"

[ArmoredDragon]

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:"simply right click"

[Gadget_Guy]

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:"simply right click"

[Anonymous Coward]

> 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"

[meerling]

The registry is actually fairly basic, it's just also huge and pretty poorly documented. Yes, you can screw up your computer pretty good if you do the wrong thing, just like messing with stuff in the system directory, or in ancient history, in the dos directory, but that's why you should be careful, have a backup, and don't play around or randomly experiment.
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: "simply right click"

[Dutch Gun]

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: "simply right click"

[WinstonWolfIT]

This will resolve a lot of pain in the npm ecosystem.

Re:"simply right click"

[geekmux]

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"

[Athanasius]

From TFA:

As you can see, Microsoft is making this change not only to Win32 software but also to Windows Store applications, as they’re playing an essential role for the future of Windows. Application manifests, which are mostly resources included in every executable file for compatibility reasons, will require apps to add a mention of this new policy, thus making sure that they support a path longer than 260 characters.

This means that unless it’s specified, the change won’t be supported, so apps will need to be updated by developers to benefit from this new behavior.

So, no, this shouldn't cause an issue unless a developer is stupid enough to put the required manifest information in without actually ensuring the code can handle the longer paths/filenames.

Re:"simply right click"

[fuzzywig]

The registry is supposed to enforce a common method of storing settings across all Windows apps. Of course, that laudable idea has then been tested by twenty odd years of pretty much everyone writing software for Windows in their own special way, and maybe about 10% bothering to follow Microsoft's standards. And of course, even different departments of Microsoft have their own ideas of how things should be done, so Office does things differently to SQL Server and so on.

tl/dr the idea behind the registry was fine, but it's been abused for years.

Re: "simply right click"

[pla]

So, no, this shouldn't cause an issue unless a developer is stupid enough to put the required manifest information in without actually ensuring the code can handle the longer paths/filenames.

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:"simply right click"

[squiggleslash]

"Really? If you have a problem with bash, how do you cope with Word with all its keystrokes? Or even the comments box on Slashdot? I think that you are making this out to be a much bigger problem than it really is."

(The problem isn't with the RegEdit UI, it's the fact a setting is buried somewhere in massive block of tens of thousands (maybe millions?) of entries, only barely made slightly easier to navigate through a hierarchy that only sometimes makes sense.)

Re: "simply right click"

[chuckugly]

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.

Re: "simply right click"

[TemporalBeing]

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 software often refers to the 260 byte character limit as either of the following:

• 260 (f.e char filename_buffer[260];
• unsigned int maxPath = 260;

Better code would have used the MAX_PATH C-Preprocessor Definition (f.e char filename_buffer[MAX_PATH]), but then that would still be a problem as the values are usually on the stack (not the heap) and pre-declared, so the code has to be updated to detect the size automatically at run-time and then allocate the proper amount. For most software this is probably not worth it as its easier to upgrade to using the Wide-Strings with a the Win32 Unicode API, especially as there are a few conversion functions (provided by MS) to do so (f.e MBCSTOWCS() - https://msdn.microsoft.com/en-...).

The bigger issue (which is somewhat mitigated by the fact its disabled by default at the application level) is how many buffer overflows is it going to cause, not just in the applications but also the libraries the applications are using. Remember in Windows development a good chunk of the libraries are provided by other vendors without source, so one not only has to make sure *their* code will support the changes but also that all their dependent libraries (dynamic [dll] and static [lib]) do too.

Finally

[fustakrakich]

I can replace my Linux machine!

Re:Finally

[bloodhawk]

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.

Re:Finally

[RatherBeAnonymous]

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

[RatherBeAnonymous]

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 * -recurse -force" in your user directory you will get path length errors on files and folders under appdata.

Re:Finally

[cdrudge]

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.

Re:Finally

[RatherBeAnonymous]

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:Finally

[squiggleslash]

Try copying your Users\{username} folder to a network share (as one does occasionally to back it up) and you'll be surprised at the number of times it cannot copy files because of length. The problem isn't usually the files you made yourself, but the \Games\Electronic Arts\Sid Meier's Civilization VIII Domination of Earth Edition\Saved Games\Automatically Saved Games\2016\January\11\10\President Abraham S. Lincoln United States of America\1048AD\Map\0000000000000000000000000000000000000000000000001.svdmap type files whose names are auto generated. This, incidentally, means the best user name to set up a new computer with is one character long (if Windows allows that, I have no idea, never really thought about the implications until now.)

Re:Finally

[AmiMoJo]

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.

Does that mean...

[__aaclcg7560]

I no longer have to maintain a relatively flat file directory structure? My directories can finally go to... plaid?!

Re:Does that mean...

[R33P]

I'd go straight for paisley or argyle, or perhaps Nova Scotia Tartan.

Re: Dear Microsoft,

[Anonymous Coward]

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

There's a good reason it's not on by default

[PhrostyMcByte]

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

[PhrostyMcByte]

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:Legacy Application Support?

[Gravis Zero]

easy fix: just recompile.

closed-source software? well now you've identified your first problem. ;)

This is not an NTFS problem but an old API problem

[kriston]

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:Why are people excited about this?

[quenda]

path names, not file names. Its quite easy when a file is buried a few levels deep. Especially with symbolic links.

Re:Login is hard to understand

[hcs_$reboot]

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.

Re:Why are people excited about this?

[Ramze]

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:Legacy Application Support?

[Fragnet]

Sure, everybody with a personal computer should just recompile. Even the 99.9% of people who don't code, right?

Re:Removable drives ... oh well

[Tablizer]

260 characters ought to be enough for anyone!

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.

There's no good reason it's not on by default

[johannesg]

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.

\\?\ Solved this...

[Macfox]

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.

Re:Oh great, another "Make it work" registry value

[brantondaveperson]

Yeah, whereas with other OSs, deleting random configuration data has no effect.

Re:Removable drives ... oh well

[dbIII]

It appears that in some industries workplace health and safety documentation policies are exactly that kind of stupid. Why I have no idea, but so many tedious artificial emergencies have cropped up from people losing access to their stuff due to insanely deep nesting with even more insane long filenames.
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 copied the files so deep that the sun doesn't shine on them" proves the wisdom of having the files on a fileserver under adult supervison of an OS that can actually get to them.
Good to see that problem is going to go away.

Paramteric had a clever solution!

[140Mandak262Jamuna]

Back in the day when most engineering applications were on unix machines and they were being migrated to windows workstation, the path name limitation was a big issue. PTC (Parametric technologies corp, a vendor of CAD/CAM software) would typically use a MAXPATHLEN of about 10*BUFSIZ but user can configure it to be bigger if they needed it. And its parts libray used very long hashes for file names. Everything from part name, author name, version number, creation date gets munged into the file names, bearing_housing_djt_284985473754653746544v .prt or something like that.

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.

Re:Login is hard to understand

[DoofusOfDeath]

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:Oh great, another "Make it work" registry value

[ArchieBunker]

Keep laughing, how many system critical variables is systemd in charge of now?

Re:Dear Microsoft,

[SirSlud]

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)