
Microsoft Removes 260-Character Path Length Limit in Windows 10 Redstone - gwbas1c
http://news.softpedia.com/news/microsoft-removes-260-characters-path-length-limit-in-windows-10-redstone-504596.shtml
======
UnoriginalGuy
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.

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

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

~~~
jongalloway2
Lots of options here: [http://superuser.com/questions/256105/how-do-i-delete-
a-fold...](http://superuser.com/questions/256105/how-do-i-delete-a-folder-
which-is-nested-quite-deep-and-avoid-file-name-too-lon)

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

------
rl3
For years, this limitation made using _npm_ on Windows miserable[0][1].

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

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

~~~
coverband
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.)

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

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

------
mrb
I am reminded of an old joke: _Windows 95 now supports long filena~1_

~~~
nomel
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...](https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-
us/subst.mspx?mfr=true)

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

~~~
rincebrain
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!

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

~~~
rincebrain
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?

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

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

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

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

~~~
satysin
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?

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

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

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

------
cm3
More info:

[https://news.slashdot.org/comments.pl?sid=9175219&cid=522154...](https://news.slashdot.org/comments.pl?sid=9175219&cid=52215475)

[https://github.com/dotnet/apireviews/tree/master/2015-08-26-...](https://github.com/dotnet/apireviews/tree/master/2015-08-26-long-
path)

[http://mspoweruser.com/ntfs-260-character-
windows-10/](http://mspoweruser.com/ntfs-260-character-windows-10/)

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

~~~
jongalloway2
Here's the commit to the .NET coreclr repo:
[https://github.com/dotnet/coreclr/commit/720732501f1d844d194...](https://github.com/dotnet/coreclr/commit/720732501f1d844d1947a20ea207e5d7f760159a)

------
PaulHoule
woohoo!

