I thought windows allowed this already with some sort of weird UNC path spec. Instead of "c:/program files/whatever", you'd do "//?/c/program files/whatever", and then it lets you use really long paths. Or is that not right? I'm just going off vague memories and [0]; I'm really not a windows guy.

[0]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

That's the idea, however this does not automatically make programs actually work with long paths. Command Prompt is a prime example, at least on Windows 7.

Yes Windows has allowed this since at least NT 4.0 with the \\?\ prefix. But the .NET filesystem apis didn't allow you to use the prefix.

What are the uses for this besides npm < 3.0? I'm super curious, the 260 limit seems like a huge flaw but in my interweb travels I haven't seen it mentioned anywhere else

We are making .NET Core OS agnostic as a general principle. The 260 char limit seems like an unwelcome Windows behavior to include in the Linux and OS X implementation. With that removed, it makes sense to also remove it from Windows. That was our thinking.

We do hear about this limitations on Windows somewhat frequently in the context of .NET. This comes from internal Microsoft teams about as much as anyone else. We were glad to remove this limitation for .NET Core.

Disclosure: .NET Team member

Here are the two .NET design review meetings where the removal of the MAX_PATH limitations is discussed: https://www.youtube.com/watch?v=lpa2OFauASM and https://www.youtube.com/watch?v=vpMqUBIAnLU

I have dealt with this in an enterprise quite frequently, dealing with people's home areas. If the home area folder is already 80 chars before the user starts creating deep folder structures with long filenames, you will run into this if you deal with a large number of users.

I've run into this problem using TFS on Windows before. Combination of folders within folders and a deep source tree would force me to abbreviate in file names and pull the source directly into C:\ rather than a preferred place.

You can also work around it by using the subst command to map a drive part way down the tree, and then switch to that drive.

Have a large vs solution.

Have a TFS build server that puts your cloned projects at not-the-top-of-the-filesystem.

It's very easy to hit that limit. It's atrocious and a joke. And Microsoft has paid me as an employee to write some ridiculous stupid workarounds for it in completely 100% managed C# code that shouldn't be bound by such stupid legacy decisions.

I hate MAX_PATH with a passion. It's one of those things that basically forces a hacky solution every, god, damn, time.

I don't see why it would need to wait for a rebranding. As far as I know it could just be the 2016 fall update to Windows 10...