3 ms·

> MaxPath Oh, Microsoft finally woke up and supports path longer than 260 chars in dotNetCore. So, the questions when will Microsoft WinAPI & and the Windows S

by frik 11y ago

> MaxPath Oh, Microsoft finally woke up and supports path longer than 260 chars in dotNetCore. So, the questions when will Microsoft WinAPI & and the Windows Shell/Explorer too? Will we probably have for Windows 11...

newjersey 11y ago
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...
purplerabbit 11y ago
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
- edgyswingset 11y ago
  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.
  - kej 11y ago
    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.
- runfaster2000 11y ago
  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
  - ghuntley 11y ago
    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 https://www.youtube.com/watch?v=lpa2OFauASM and https://www.youtube.com/watch?v=vpMqUBIAnLU https://www.youtube.com/watch?v=vpMqUBIAnLU
- klausjensen 11y ago
  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.
- ossreality 11y ago
  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.
tsuraan 11y ago
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/aa365247(v=vs.85).aspx#maxpath https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
- poizan42 11y ago
  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.
- ashmud 11y ago
  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.

by frik 11y ago

newjersey 11y ago

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

purplerabbit 11y ago

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

edgyswingset 11y ago
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.
- kej 11y ago
  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.
runfaster2000 11y ago
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
- ghuntley 11y ago
  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 https://www.youtube.com/watch?v=lpa2OFauASM and https://www.youtube.com/watch?v=vpMqUBIAnLU https://www.youtube.com/watch?v=vpMqUBIAnLU
klausjensen 11y ago
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.
ossreality 11y ago
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.

tsuraan 11y ago

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/aa365247(v=vs.85).aspx#maxpath https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

poizan42 11y ago
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.
ashmud 11y ago
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.