Thanks to Microsoft's fanatical dedication to compatibility I don't see how it will ever get fixed. I think they could take a lesson from Apple here and have DLLS/EXEs contain SDK versions against which they are built, then mandate that Windows 10 apps must support a larger MAX_PATH. Of course if they were into learning lessons, they'd have done fat binaries so a single install could easily support 64-bit and 32-bit (or a single DLL could contain 64-bit and 32-bit versions).
For those not in the know, MAX_PATH and PATH_MAX (ugh) are defined in the Windows headers as 255. Because it was public people copied that constant and spread it around. So many apps and libraries out there are hard-coded to expect 255 that even if you change it in the Windows headers a million things will still be broken.
Even if you overcame that limitation, you'd have a situation where paths no longer worked reliably if they got passed around (or worse, long paths would trigger buffer overflows in poorly written apps and drivers).
You could fix it by passing apps not declared as large-path aware a shortened virtual path but the testing/edge case burden would be enormous.
So this is an example of a really quick decision one programmer probably made by themselves many years ago that we are forced to live with because the pain of changing it is too great compared to the benefit we'd receive.
Otherwise, yeah - we don't like it either... here's the not-closed uservoice request ;-) https://windows.uservoice.com/forums/265757-windows-feature-...
EDIT: Re: fish: Indeed - we have some big fish to fry, but luckily msft is a big company that can fry multiple fish at a time. Personally, I'm excited to help improve the Node tooling story by frying this fish, and passing our learnings and feedback onto the the other teams @ msft so that they can improve their recipes. Ultimately, we strive to have a complementary set of fried fish. And maybe some vegetables too... :)
- connect is for filing bugs
- uservoice is for "ideas and suggestions"
How people use it, of course, is a completely different story...
And then some teams (like us) have public issue trackers, which are the best approach if available because everything goes directly to the team: https://nodejstools.codeplex.com/workitem/list/basic
I think Ms is doomed to get people complaining about unrelated junk any time they open a platform up.
If you need developer feedback maybe require the UX to be creating Pull requests describing the issue? Kind of like how pullup.io works?
http://stackoverflow.com/questions/21194530/what-does-mean-w...
https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
* https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
With regards to the technicalities of max_path itself... the issue is with the .NET file I/O API, which doesn't allow you to use \\?\ paths to work around it, and is too big for our team in particular to do much about. Here's a good article that might provide a little more context (it's a little old, and these "plans" they speak of never actually materialized.)
http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-path...
That said... we don't like it either, and we are still thinking about what we can do.
I don't know, I was cussing out both node.js and Windows. "Let's put all the dependencies in subtree even if they repeat 20 times throughout or paths start wrapping around 3 times at the terminal".
But the fact that Unicode functions don't expand adds an interesting problem for us; the MAXPATH respecting (and outdated) _A filesystem functions can cause a collision for non-expanded paths we get to fun things where you can have different FILE objects if you use old _A functions vs _W functions. The inverse is also true where you can collide by moving from _W to _A.
So! If we do start using old _A functions we actually can cause problems by directing to new files that would cause expansion because of file expansion being turned on.
* https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
* https://msdn.microsoft.com/en-us/library/ms813802.aspx
PS. Don't get me started on FS permissions...
Doesn't look great for node and it shouldn't be their problem.
More like "We landed on the moon but sometimes the door won't open"