Microsoft Removes 260-Character Path Length Limit in Windows 10 Redstone | Hacker News Reader

Microsoft Removes 260-Character Path Length Limit in Windows 10 Redstone

news.softpedia.com

111 pointsgwbas1c55 comments

Inaccurate title.

Windows currently doesn't have a 260 character path length limit. However some legacy Win32 APIs only support up to 260 characters for backwards compatibility and old file system reasons.

If you use UNC paths you can have a path with 32,767 characters in it, 255 characters per element (e.g. a single folder/file name of 255 characters).

To quote MSDN:

> The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".

All this GPO policy does it change existing non-unicode Win32 APIs to support paths beyond the 260 character limit. However this likely won't work on pre-Windows 10 versions of Windows, non-NTFS filesystems, and just having long file/folder names may within itself break older software.

If I recall correctly this change didn't just need a GPO setting, but also a .manifest file for the executable (often embedded)? In order to tell the OS that "Yes I am now a Windows 10 long path aware application; bring it on." Otherwise yeah, it would wreak havoc on apps using buffers with MAX_PATH size.

> However some legacy Win32 APIs only support up to 260 characters for backwards compatibility and old file system reasons.

Legacy or not, this affects all .NET applications and also to some extent NodeJS (with its crazy node_moules mess) and you have to apply all kinds of crazy workarounds for this not to come back and bite you.

The amount of builds I've seen broken over stuff like this is ridiculous.

If they can get this fixed proper, I'd love to offer the MS engineer who made this happen a beer or twelve.

speaking of this, how do you do delete those crazy node_modules in Win10 from the command line? Powershell or CMD

rmdir should do the trick:

https://www.microsoft.com/resources/documentation/windows/xp...

Although installing MSYS2 http://msys2.github.io/ provides a far superior command line environment IMO and then you can just use rm.

https://www.npmjs.com/package/rimraf

Lots of options here: http://superuser.com/questions/256105/how-do-i-delete-a-fold...

If you have 7-zip installed, you can open the parent directory in 7-zip file manager and delete it from there.

One approach (which I've used in our build definition where we ensure we have a clean workspace) is to rename all folders to "a" and recursively dig into them before deleting.

So \a_quite\long\path\with_files\module.js becomes \a\a\a\a\module.js

And you can usually delete that quite fine.

It's terrible. It's ugly. But it works.

This is second hand information; but a developer at my place of employment tried to get around path limitations by applying UNC paths and was met with many, many barriers where windows internals themselves only understood the legacy version of paths and the UNC "limitless" approach didn't actually work.

this was on windows 7 though and relatively recently, perhaps it's better in 8 and 10.

Indeed it does. You could talk about Windows the entire operating system, or you could talk about Windows as Win32, but either way - yes - they both have 260 character path length limits _by default_.

I realize that you're saying that Win32 doesn't have a hard limit of MAX_PATH since you can use Win32 file namespace paths (the `\\?\` prefix) to specify long paths. And yes, that's technically correct, you can. But realistically, unless you carefully control the paths that you're writing and no other program is using them, you're pretty much shooting yourself in the foot by trying to do that.

This is because most apps simply use the Win32 APIs with normal paths and not Win32 file namespace paths. So sure - you can write a file that has a name that's 1024 characters, or a file named `CON`, or a file named `hello?`, but only other programs that wisely use `\\?\` paths can do anything with that. Which is basically nothing except the program you just wrote.

It certainly doesn't include almost anything that Windows itself put down during installation. `cmd`, the Windows Shell, the whole of the CLR? None of these can read the file you just wrote.

So the title seems quite accurate to me.

I have hit this limit when trying to make backups with rdiff-backup (written in Python) on relatives' computers. I found out about UNC paths that way, haven't managed to get rdiff-backup to accept them. Does anyone know how to do that?

> rdiff-backup (written in Python)

"If you have ever needed to work with UNC paths in a Python script for Windows, you might have experienced the same dilemma that we did. What’s the problem? Python has virtually no support for UNC."

http://developer.covenanteyes.com/unc-paths-with-python/

"As tiny as our minority might be, we wanted to deal with these difficulties once and for all. I introduce to you the win_unc library."

Hmm. This looks like it deals with UNC paths. I think the parent is asking about what are sometimes called "Win32 file namespace paths" - or at least defined as such by the MSDN article that is canonical https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

These are sometimes erroneously called UNC paths because, well, they _look_ like UNC paths. But UNC paths are used to refer to a path on another host. (In fact, you can specify UNC paths using the Win32 file namespace using the `\\?\UNC\server\resource` mechanism.)

It looks like win_unc will help with UNC, but it looks from a quick glance that it will not help with `\\?\` paths.

I've never used it. If it doesn't work and somebody really needs to have "\\?" in Python and doesn't want to develop the Python extension in C himself, I'd be willing to develop it, but for money, serious consulting rates.

For years, this limitation made using npm on Windows miserable[0][1].

[0] https://github.com/nodejs/node-v0.x-archive/issues/6960

[1] https://github.com/npm/npm/issues/3697

I was just about to suggest increased adoption of nodejs on Windows is most likely what triggered this change.

(I don't even use node, but if a project I'm interested in has a bunch of node modules in it, I'll have to stop and spend time to fight the path length errors.)

Not that you should do this because it's a horrible product, but if you ever installed IBM WebSphere Portal Server on Windows, you run into all kinds of issues because of the path name length. It would install partially by unzipping into long paths and then you would be unable to uninstall it because their uninstaller would try and hit the paths directly and fail.

Ah ! Serves them right for inflicting the same problem on applications that install on AIX using the builtin tar and can't find their files after due to the path lenght limitations.

It's not even a problem in npm 3.# because it doesn't do nesting by default anymore.

Good point. Looks like npm 3.x emerged from beta late last year.

I edited my original post accordingly, changing it to a more reminiscent tone.

I am reminded of an old joke: Windows 95 now supports long filena~1

C:\ONGRTLNS.W95

In Win32, a funny trick I found to get around the path limit was to use subst [1]. You could subst a long path to a drive letter and continue adding directories from there. No one directory could exceed the limit, but it made accessing the path nearly impossible, without setting up the subst first. None of the virus scanners I tried were able to access that deep or flag the bad things I tried putting there.

[1] https://www.microsoft.com/resources/documentation/windows/xp...

It makes sense for this be opt-in, but I'd like to know how they want to achieve compatibility with apps that didn't adapt and are given such a file.

Eventually, one presumes they'll have a flag in the Compatibility tab for applications, "does not believe in long paths", rather than an opt-in/opt-out.

It'll be great - like the 8.3 transition all over again!

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

So if it doesn't have the manifest entry, the program will be assumed to not handle longer paths.

This sounds reasonable. Case in point are other features which required a manifest with the right entries.

Yeah, I'm not surprised; that's generally how they handle these sorts of things. See /LARGEADDRESSAWARE.

Thank you, I had not noticed that in the original article, only the registry key.

That puzzles me, then - why have a registry key to toggle being able to manifest that at all?

So that Group Policy can turn it off. For instance, an Enterprise doesn't want anyone using super long paths, even if software is manifested to handle it, because some of their NTFS drives are secretly NetWare shares of FAT volumes still and things will go wonky.

The more interesting question is why doesn't this build default that registry key to On in this Build. My presumption here is that the Win32 subsystem changes are possibly significant and there are some backwards compatibility concerns and so this is "feature flagged" until it's been tested more in labs/real world exposure.

I guess they simply won't. Apps that don't adapt can't open the file. Period.

Given how drastically Microsoft changed in the last couple years, I wouldn't be surprised if they distanced themselves from the level of compatibility guarantees they issued in the past.

EDIT: I don't think it would go down well, if some files cannot be opened in all applications only because of the path. I mean, Windows is the biggest enviroment for the most diverse set of desktop applications right now, so refusing to open files because your app doesn't support the path sounds unreasonable but I cannot think of a solution myself. Thus I'd like to know how they're approaching this.

I'd say they will not enable that policy by default, at least for a very long time.

Possibly a junction-like mapping into the "physical" position in the MFT. Perhaps something like "\\?\$MFT\positioninmft\possiblyshortenedfilename.ext". Somewhat similar to the various mappings for 32-bit programs running on 64-bit Windows.

A few weeks ago after installing bash for Ubuntu, I created a 700+ character path in bash and was able to see it from explorer. I suspect, that this has been supported in Explorer and bash on Ubuntu before this release.

Yes but what happens when Windows programs try to interact with files in that path?

That's why "Bash on Windows" will likely never be used in a production environment, and personally as a developer I see it as creating more problems than it solves. Because it can't be used in production you're limited to apps that either run in Linux or run in Windows, but not apps that take advantage of both systems.

In the end I mostly just end up using Linux to program apps that won't even run on desktop Windows (do people still develop desktop app for windows and make money doing it?). I do webdev, android, iOS, and some enterprise network applications. I don't even really need the windows desktop.

If MS wants to attract developers they should fix the font rendering.

> do people still develop desktop app for windows and make money doing it?

Absolutely. I sell a small utility application that's a native Windows application.

Oh cool you are the guy who made BatteryBar :) I bought that back in 2010 I think, don't use a laptop much these days so not used it in a while. Nice little app though.

Just out of personal curiosity but what is BB developed with?

> do people still develop desktop app for windows and make money doing it?

I have been doing Windows desktop development in the last three years and there are lots of requests for doing so in the enterprise space.

More than we can fulfill actually.

Last time I tried to do some web dev on a Windows machine, I had to install bower to install a web component. So I installed npm, then installed bower, then installed the component.

When I was finished, I tried to delete bower, but Windows wouldn't let me. It had installed all of its dependencies, which had installed dependencies of their own, each one nested deeper and deeper, node_modules after node_modules, far exceeding 260 characters.

I forget what trickery I had to resort to in order to delete that folder. It took a bit of Googling and I had to follow instructions I found on StackOverflow.

On a shared network drive I had to resort to mapping a subdirectory deep within the base directory to a new drive letter to recover data after someone copy/pasted a folder with its own deep-nesting directory structure into it.

Would've been nice if Windows wouldn't have let them do that in the first place (given the constraint on file paths).

Makes you wonder if the people developing windows are even using their own product as a development platform. I imagine they use some unix or unix like platform to program windows and thus the developers themselves rarely run into problems like this, so they become unaccounted for.

It's probably more due to having many large product groups (or subsystem groups) that don't cooperate as closely as one would like them to. For example NTFS doesn't have a 260 limit but the userland above and therefore the APIs do.

Windows developers have seldom this problem, because we don't do endless nesting of folders.

People developing Windows are unlikely to be using npm. And outside of npm (and similar occasional app that uses a very deeply nested directory tree for storage), you don't run into this issue all that often.

They're using Windows in development, and the "problem" itself is a compatibility thing to deal with now-antique versions of windows. The underlying kernel can deal considerably longer filenames, it's easy to create paths that can use considerably longer filenames, it's just certain UI portions that can't.

MS tries to keep backward compatibility at an almost obsessive level, warts and all. The unfortunate thing about maintaining backward compatibility to an almost obsessive level is that you get artifacts like this limit. While the limit should have been removed some time ago, it became so known, easy to work around, and seldom encountered that it was felt to cause more problems than it solved.

To be fair that's a flaw an npm. If the underlying platform has these kinds of limitation, then they really should be taken into account when porting software to that platform.

If someone ported software to Linux from Windows, without taking into account that Linux cares about the upper case and lower case letters in filename and paths, then you can't really claim that it's Linux that's broken.

Later versions of npm install dependencies in a flat structure with duplicates removed, instead of a deep nested tree for each packages sub dependencies sub dependencies sub dependencies and so on... It should help to reduce these problems.

> To be fair that's a flaw an npm.

Ummm, not so sure considering all those modules still worked when you'd require them in node. The problem was that you couldn't easily delete those files from the file system. So it is actually the fault of the OS for allowing you to create those files/folders if it wasn't going to also be able to handle deleting them.

There's a whole different API. https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... But it pretty much comes down to adding \\?\ to the front of your path.

That is a npm issue.

I do web development on Windows using Java and .NET stacks, never had the problem.

More info:

https://news.slashdot.org/comments.pl?sid=9175219&cid=522154...

https://github.com/dotnet/apireviews/tree/master/2015-08-26-...

http://mspoweruser.com/ntfs-260-character-windows-10/

Hopefully there will be a matching change in the server edition OSes and .NET framework soon.

Here's the commit to the .NET coreclr repo: https://github.com/dotnet/coreclr/commit/720732501f1d844d194...

woohoo!

Reply on news.ycombinator.com