MSBuild should handle paths longer than MAX_PATH #53
15 participants
MSBuild team triage: This isn't a change we're looking to take anytime soon as it would be fairly substantial with implications on dependent tasks and tools.
[...]it would be fairly substantial with implications on dependent tasks and tools.
Could you be a bit more specific?
I'm still curious as to what the substantial implications of an incremental fix for MSBuild in isolation are, exactly.
In general, you'd have to have all of the other things you're using understand long paths. There's been a number of discussions internally and externally about the MAX_PATH issue and they always eventually boil down to: "If we could rewrite everything we'd be good but we can't so there's an infinite sea of compat risk here :-(".
So... maybe some day?
The key issue here is that it doesn't really matter if MSBUILD is updated. It's not an island. it passes paths to lots of other things (OS apis, tools etc) and updating yourself in a way that doesn't break them is a Hard Problem (tm). Almost certainly not impossible but there's lots of other work with better payoffs.
Hmm. The way I see it, is that the entire toolchain is not compatible with paths longer than MAX_PATH, and thus by (incrementally) fixing a single component will not lead to toolchain-wide regression. It'll just be broken in a different place - the entire toolchain, when used as a system, will still be broken, but in a slightly smaller way.
It's even worse, by the way, as MAX_PATH was only the "maximum total file path length" for FAT16, and pre-Unicode/pre-NT APIs. Any documentation that says MAX_PATH is the longest possible file path is horribly wrong! MAX_PATH should really have been named MAX_FAT_PATH or MAX_PATH_COMPONENT; any program that was built after Windows NT 3.1 (yes, July 27, 1993, the earliest default use of NTFS that I know of) to use Unicode APIs with the assumption that MAX_PATH is the longest possible file path is, and always was, terminally broken. GCC 4.9-style broken.
I can even find discussions dating more than ten years back, of developers realizing that assuming MAX_PATH is the maximum length of a path is an outdated (ridiculous) assumption.
Any components that have been retroactively "fixed" to ensure compatibility with only paths that are MAX_PATH or shorter - well, that's just crazy.
Also, I can't imagine that we can break the OS APIs themselves by using them in a documented manner.
So yeah, it's a Hard Problem™, and I know that we don't yet have proper time travel, but if we attack it incrementally, we either make small (and effectively non-functional) improvements, or expose bugs/unforeseen design issues in other components.
I say effectively non-functional, because those components that can't handle MAX_PATH are already broken for paths longer than MAX_PATH. I can't imagine that those applications rely internally on the exact full path name that's given to them.
Furthermore, I imagine that OTHER toolchains use MSBuild in ways that are crippled by the MAX_PATH limitations.
...and while new features/better compliance are nice, I think they're counterproductive/add silly complexity if the core components that they're built on are shaky and fail in unexpected ways (e.g. MAX_PATH limitations). Putting it off into the future only makes it harder to fix.
Lastly, let me remind you of the nearly 3000 users who voted on "Fix 260 character file name length limitation" before it was declined. There are still users commenting on the issue with frustration.
Here's an idea
How about you/we go ahead and make the changes to MSBuild, make it available as a "preview" or "technology demonstration", and see what (if anything) breaks.
You seem to understand the issue pretty well. I don't disagree that isn't a frustrating experience some times but they have finite resources and can only take so much risk. I'd be more interested in them making sure cross plat is brought up cleanly but it's up to them. I'm sure they appreciate your enthusiasm and feedback. I'll bow out of this issue for now.. lots of other bugs to track down.
@ariccio If you have the inclination, I say go for it. Everybody will eventually benefit, especially if more pieces of the toolchain go open source. Saying that it can't be fixed because everything else in every possible toolchain would also have to be fixed immediately is, quite simply, a non-starter and completely unrealistic. The whole point of going open source is to let people scratch their itches, especially when Microsoft doesn't have the resources to do it themselves...
One way to minimize the risk associated with backwards and toolchain compatibility that Microsoft keeps talking about is to ensure that the current limitation remains the default behavior while making it possible to opt-in to longer paths. The opt-in mechanism can be via any relevant configuration mechanism, including a new command line option, a build file setting, a registry setting and/or some other mechanism.
I'm also in.
Especially down the road to xplat, where *NIX operating systems do not care about a 260 char path length at all. IF set at all (this may well be -1 to indicate that there is no limit) it for example defaults to 4096 on x86 Linux. On OS X's HFSP the max path length is unlimited (while the file name is limited to 255).
So, in fact, this issue here is a blocker for xplat.
Yes, there may be other places in VS, TFS and other tools that have problems with this, but as long as we want to simply 'MSBuild mysolution' on commandline or on an CI system like AppVoyer or Travis, and happen to have paths longer than 260 chars there, it should not artificially prevent us from doing so.
I also don't see how removing this limitation would break other stuff.
If other stuff can't handle paths longer than 260 chars, it already IS broken. It won't break more. I would just break elsewhere.
And: Yes. Especially because MSBuild is not an island, but a part in a chain, someone has to start. And MSBuild is the perfect place because it can be used more or less standalone on new DNX projects (because, honestly, Sake is the totally wrong thing for building stuff), and it could be the door-opener to fix the stuff in other places too. Best thing is, that others like the VS or TFS team won't have excuses like 'MSBuild doesn't support that, so why should we change that?' anymore.
When talking about where to spent time, it's mostly the time of the community that will be spend here. So why not simply start here, by removing that artifical limitation, pass longer paths around where necessary and, who knows, maybe much less is broken that is currently being thought off and a lot of stuff simply starts to work out of the box?
Mediaeval issues like this still prevent us from using proper folder structures and proper file/folder names still. And it's not a corner case: for us all of our builds would fail if not copied to the drive root of the build server!
Glad to see that people are still voicing their support. Fixing this arcane issue is certainly not a glamorous job - hence the foot-dragging - but it's a desperately important one.
I'd also see this open 10 years from now if noone does a start!
But we also need a Api for full length paths directly in dotnet core!
Work is now in progress to enable long path support for .NET Core. I think the goal is to also add this to the full .NET Framework (@terrajobst can probably confirm whether this is the case).
Once this is done it should be a lot easier to add support for long paths to MSBuild- long paths should "just work" when they are passed to .NET APIs, without having to add the \\?\ prefix.
@AndyGerlicher Should we consider re-opening this issue?
Should we consider re-opening this issue?
Technically, it is still open.
But, if long path support is on it's way to the .NET Core, then I'd be totally cool treating this as a tracking issue.
Also running in to this same issue (with ASP.NET 5 DNX Beta 7 website publish operation):
System.ArgumentException: The name can be no more than 260 characters in length.
Do you have an update on when this will be resolved?
Thanks!
I know there's been some progress getting long path support in the core clr, but I think it will be a while before it's ported back to the desktop framework. Until that happens, this just isn't really high on our priority list. It's something we would probably do in xplat first since we'll get the core clr updates sooner, but it's not on our radar right now.
Given how far we are with making progress on solving it in .NET Core, I wouldn't invest in handling it in MSBuild. At least for the .NET Core based version it would get a free ride by doing nothing. .NET Framework is a bit more out, but again, our goal is to port those changes back and make it transparent which would mean that MSBuild would get a free ride.
Either way, I don't think doing a duct tape fix in MSBuild is currently worth it.
Completely agree. However the one caveat is we have several places in our code where we check if the path is over some const defined in our code. So we won't quite get a free ride.
If that's the case, I'd encourage you to remove those. This isn't even a long path thing; for cross-platform alone you don't want to restrict paths on Mac/Linux to a Windows specific limit. In other words, removing those checks immediately benefits some customers.
(Also, on Windows you don't really lose anything. You might trade errors against different errors or run for longer before detecting it but that seems like the correct behavior anyways moving forward.)
Given how far we are with making progress on solving it in .NET Core, I wouldn't invest in handling it in MSBuild.
I'm glad to hear that that project is progressing nicely! Any idea on how long "a bit more out" is?
Of course, it's software, so I wont hold it against you as a "deadline" of some sort :)
We don't have a timeline but I'll keep you posted via our design reviews, Twitter and so on. Hopefully the dev driving it can give us an update in a couple of weeks.
Windows will soon get over this problem: http://news.softpedia.com/news/microsoft-removes-260-characters-path-length-limit-in-windows-10-redstone-504596.shtml Will this expedite the progress?
@Piedone We discussed this a bit internally, and it definitely helps. There are a couple of complicating factors:
- Backwards compatibility: we need to work where Visual Studio does, and we'll probably want to keep our (somewhat nicer) error messages on older OSes.
- Full .NET Framework: the recent Redstone news talks about Win32 and UWP apps, but it's not clear to me whether a change to the (full, installed) .NET Framework would be required to support this for managed apps on Windows.
That said, I don't think this is "distant future" any more.
Note to future implementer: make sure eventual fixes for this include FileTracker and Tracker.exe.
(I just had cause to poke into that code and saw MAX_PATH all over the place.)
The path for desktop framework is clearer now. .NET 4.6.2 supports long paths in System.IO. Since we're not targeting 4.6.2, MSBuild will have to opt in with this app.config section:
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />
</runtime>
As seen in Fix 260 character file name length limitation, there's quite a bit of support for better longer-than-
MAX_PATH-filename handling.Will Buik's response w/regard to fixing it was:
I wondered, how big can those architectural changes be (for MSBuild)?
According to Naming Files, Paths, and Namespaces: Maximum Path Length Limitation, (which I have mirrored here ):
(emphasis mine)
...Which means that wherever MSBuild uses full paths, we
canshould be able to just prepend"\\?\"to ask for a long path.Of course, we'd need to rework the existing path-length-workaround hack.
This won't fix the whole ecosystem, but it'll get us just one step closer.
I'd like to fix this myself (it seems simple enough), so in accordance with:
...this is the suggested issue.
I'm a native developer at heart, not an experienced C# developer, but this shouldn't require anything crazy.
Direct references to MAX_PATH: