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. 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. 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.
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. I'm a native developer at heart, not an experienced C# developer, but this shouldn't require anything crazy. Only contributions referencing an approved Issue will be accepted.As our process matures and our experience grows, the team expects to take larger contributions. Contributions must be discussed with the team first, or they will likely be declined.
I'd like to fix this myself (it seems simple enough), so in accordance with: This won't fix the whole ecosystem, but it'll get us just one step closer. Of course, we'd need to rework the existing path-length-workaround hack.
#Long path tool vs long path fixer full#
Which means that wherever MSBuild uses full paths, we can should be able to just prepend "\\?\" to ask for a long path. For example, "\\?\D:\very long path".īecause you cannot use the "\\?\" prefix with a relative path, relative paths are always limited to a total of MAX_PATH characters. To specify an extended-length path, use the "\\?\" prefix. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. I wondered, how big can those architectural changes be (for MSBuild)?Īccording to Naming Files, Paths, and Namespaces: Maximum Path Length Limitation, (which I have mirrored here ): Dedicating resources to this work item would come at the expense of many other features and innovation. We understand that this can be a frustrating issue, however, fixing it requires a large and complicated architectural change across different products and features including Visual Studio, TFS, MSBuild and the. Will Buik's response w/regard to fixing it was: 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.
0 kommentar(er)
