Base types, Collections, Diagnostics, IO, RegEx…
My original part 3 blog caused confusion, mostly because it didn’t tie together loose ends and explain that an immediate .NET “solution” is at best partial. To minimize confusion and answer questions in the comments, I decided to do a complete overhaul and link to the original (here).
Win32 file-naming conventions include the MAX_PATH (260 character) restriction. A subset of Win32 APIs allow you to work around the MAX_PATH restriction by adding the \\?\ prefix.
Recall that these are the problems with the \\?\ prefix:
#2 isn’t obvious to many people so let’s focus on that.
.NET relies heavily on Win32 and isn’t always able to provide clean workarounds to Win32 restrictions. If we introduce a concept that has partial Win32 support, we either:
An example of (a) is: you move a file to a location enabled with the \\?\ prefix, and then pass that path to another .NET API, which results in a call to a Win32 API that doesn’t support \\?\. (e.g. LoadLibrary). This sequence of operations would fail.
An example of (b) is: we try to make things work for Win32 functions that don’t support \\?\. This would be a major undertaking of rebuilding Win32 functionality or re-building a file system in the .NET layer (for example, we associate with shorter paths that can be accessed). Either approach is extremely risky and error prone, and we don’t see this as an option at the moment.
Currently, .NET doesn’t allow you to use the \\?\ prefix at all. Let’s consider how .NET might enable it:
We also considered off-by-one attempts to soften the MAX_PATH limit, such as auto-shrinking which is done in the Windows shell. It’s compelling because such a path can be supported by other Win32 APIs and the shell. However, based on feedback, we think this just makes the story more confusing. The lack of consistency makes it useful to only corner-case scenarios, and certainly apps wouldn’t want to depend on it.
We won’t be able to provide seamless long path support throughout .NET until something is done on the Win32 side to broaden support of long paths throughout their APIs.
As a mitigation to at least provide parity with Win32, we propose to allow use of the \\?\ prefix (described in #2 above) to avoid the MAX_PATH limitation. The caller must explicitly use this prefix, at best aided with a helper API as follows:
String longPathEnabledName = Path.ToLongPath(@"C:\veryLongPath...\veryLongName.txt");
FileStream fs = new FileStream(longPathEnabledName);
This enables use of long paths throughout the System.IO namespace. Support of long path files outside of System.IO will be limited by support of underlying Win32 APIs.
This is not a real solution, but this provides core file (reading, writing, etc) functionality for long path files, which is compelling for certain types of apps. Such apps are best described as closed-system, file reading/writing-focused apps.
Some possibilities include:
PingBack from http://blogs.msdn.com/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx
I'd rather see paths abstracted out as a class rather than being strings.
I know this would be a monumental change, but it would make working with paths so much easier e.g. getting at the individual parts of a path, not having to worry about separator charactors, or whether you have to trim trailing slashes before appending, etc.
Plus you wouln't have to worry about what's going on under the hood - as long as everything in the BCL accepts a path object parameter (rather than a string) then the \\?\ format could be used at the very last step internally by the BLC.
There's still the problem of underlying Win32 APIs not supporting \\?\ though. That's definitely a pain!
>> I'd rather see paths abstracted out as a class rather than being strings.
I completely agree. It would confine the many problems of working with paths as strings to as small an area as possible.
You're right that it would be a monumental change to introduce this in the public surface area, but any progress towards this -- at least internally in the BCL -- would help.
I'm definitely interested in that.
I would expect use of long paths outside of System.IO to throw an exception where such use is inappropriate.
Your proposed solution looks quite good to me. Thanks! It would be very nice if Path.ToLongPath accepts relative paths, too, and automatically prepend the current directory. (It should accept any kind of path, including UNC, and "do the right thing".)
Regarding the ideal solution, I do hope that you are asking (strongly) the Windows team to add full support for long paths in Windows 7.
An abstract class for paths would be very welcome. It could be something like Perl's File::Spec (but better).
The is one more thing you should do: document a clear set of best practices for developers who want to support long paths using .Net.
The question is who do we have to "encourage" to get it done "right", ie. Ideal #1/Win32?
Isn't it time that the OS really supports long paths?
What can we do, as users, who do we email, etc to make this a higher priority for the OS/Win32 team?
My feeling (having "sort-of solved" this already via P/Invoke & //?/) is that without OS support, having half may be worse than having none.
Know what I mean? That if .Net makes it easier to create long paths, but Windows Explorer, command line tools del/ren/etc, gacks on them that we'll be creating even worse support headaches for ourselves. Yes, "with great power..." and all that, but still.
That said, I TOTALLY applaud you and the BCL team for working this issue and keeping it alive, and I dig that you're working on a work around. You guys rock!
But I still feel we really need a "real" solution road map. So who do we have to chat at to get the Win32 API to move forward?
Wow, thanks for the update Kim! Kudos to you and the BCL Team for your thoughtfulness and hard work on this issue!
Any idea when and what Framework version the proposed solution would show up in the BCL?
Thanks for the feedback! We're still working out the scheduling issues so I can't give a timeframe yet. I'll definitely look into where this feedback can be given on the win32 side (regarding the ideal solution). I'll get back soon.
Looks like a great solution, thank you!
Another method you might consider adding would be "static bool Path.IsLongPath(string)"
In an ideal world it would be nice if developers didn't need to know if something was a long path, but in might be a good stop-gap solution until more Win32 functions support long paths.
Thanks again! I really appreciate all the hard work that has been done - definitely not an easy problem to solve!
Finding Path lengths greater than MAX_PATH