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"

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

[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.

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

[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.

Does that mean...

[__aaclcg7560]

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

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.

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

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