>
> As seen in \[Fix 260 character file name length limitation\](http://visualstudio.u…servoice.com/forums/121579-visual-studio/suggestions/2156195-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:
>
> \> 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 .NET Framework. Dedicating resources to this work item would come at the expense of many other features and innovation.
>
> I wondered, how big can those architectural changes be (for MSBuild)?
>
> According to \[Naming Files, Paths, and Namespaces: Maximum Path Length Limitation\](https://msdn.microsoft.com/en-us/library/aa365247.aspx#maxpath), (which I have mirrored \[here\](https://github.com/ariccio/altWinDirStat/raw/master/filesystem-docs-n-stuff/Naming%20Files%2C%20Paths%2C%20and%20Namespaces%20%28Windows%29.pdf) ):
>
> \> 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. 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). To specify an extended-length path, use the \`"\\\\?\\"\` prefix. For example, \`"\\\\?\\D:\\very long path"\`.
> \> \_\[other stuff\]\_
> \>
> \> Because you cannot use the \`"\\\\?\\"\` prefix with a relative path, \*\*relative paths are always limited to a total of MAX\_PATH characters\*\*.
>
> \_(emphasis mine)\_
>
> ...Which means that wherever MSBuild uses full paths, we ~~can~~ should 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:
>
> \> - Contributions must be discussed with the team first, or they will likely be declined. As our process matures and our experience grows, the team expects to take larger contributions.
> \> - Only contributions referencing an approved Issue will be accepted.
>
> ...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:
> \- \[NativeMethods.cs#L15\](https://github.com/Microsoft/msbuild/blob/82177a50da735cc0443ac10fa490d69368403d71/src/Utilities/TrackedDependencies/NativeMethods.cs#L15)
> \- \[NativeMethodsShared\_Tests.cs#L53\](https://github.com/Microsoft/msbuild/blob/f5d9cfdb9b7d0e8f29c88d21e2a08dc1d167aa9f/src/Shared/UnitTests/NativeMethodsShared\_Tests.cs#L53)
> \- \[NativeMethodsShared.cs#L318\](https://github.com/Microsoft/msbuild/blob/82177a50da735cc0443ac10fa490d69368403d71/src/Shared/NativeMethodsShared.cs#L318)
> \- \[NativeMethodsShared.cs#L540\](https://github.com/Microsoft/msbuild/blob/82177a50da735cc0443ac10fa490d69368403d71/src/Shared/NativeMethodsShared.cs#L540)
> \- \[NativeMethodsShared.cs#L750\](https://github.com/Microsoft/msbuild/blob/82177a50da735cc0443ac10fa490d69368403d71/src/Shared/NativeMethodsShared.cs#L750)
> \- \[FileState.cs#L293\](https://github.com/Microsoft/msbuild/blob/82177a50da735cc0443ac10fa490d69368403d71/src/XMakeTasks/FileState.cs#L293)
> \- \[ComReference.cs#L460\](https://github.com/Microsoft/msbuild/blob/82177a50da735cc0443ac10fa490d69368403d71/src/XMakeTasks/ComReference.cs#L460)
> \- \[TargetsFile\_Test.cs#L2041\](https://github.com/Microsoft/msbuild/blob/82177a50da735cc0443ac10fa490d69368403d71/src/XMakeBuildEngine/UnitTests/TargetsFile\_Test.cs#L2041)
So, if I am using ITK v5.0, I get this error:
> ITK build directory path length is too long (55 \> 50).Please set the ITK build directory to a directory with a shorter path.
However, modifying the ITK CMakeList with the following lines makes the compilation working fine:
```
if( CMAKE_HOST_WIN32 )
if(${CMAKE_SYSTEM_VERSION} VERSION_GREATER "10.0.14392") # Win10 version 1607
set(_LongPathKey LongPathsEnabled)
execute_process(COMMAND reg query HKLM\\SYSTEM\\CurrentControlSet\\Control\\FileSystem /v ${_LongPathKey} OUTPUT_VARIABLE _output)
string(REGEX MATCH "${_LongPathKey}.*REG_DWORD.*[0-9]x([0-9])" _regex ${_output})
if (${CMAKE_MATCH_1})
set(ITK_SKIP_PATH_LENGTH_CHECKS 1 "Skips max path length checks. These checks can be disabled for Windows version 10.0.14393 and later if registry key HKLM\\SYSTEM\\CurrentControlSet\\Control\\FileSystem\\LongPathsEnabled is set to 1 and all tools support long paths. As of January 2018, MSBuild and Visual Studio do not support it yet.")
endif()
endif()
endif()
```
I didn’t know if it would have been better to create an Issue on your GitHub or to directly propose a Merge Request on your release branch. Let me know.
By the way, I am using Visual Studio 2017:
> – Selecting Windows SDK version 10.0.17763.0 to target Windows 10.0.18362.
> – The C compiler identification is MSVC 19.16.27035.0
> – The CXX compiler identification is MSVC 19.16.27035.0
> – Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x64/cl.exe
> – Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x64/cl.exe – works
> – Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x64/cl.exe
> – Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x64/cl.exe – works
> Microsoft (R) Build Engine version 15.9.21+g9802d43bc3 for .NET Framework
Regards,
Thibault
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [February 7, 2020, 3:54pm UTC](https://discourse.itk.org/t/enable-long-path-compilation/2691/2 "2020-02-07T15:54:06Z")
Welcome to the community Thibault.
Proposing a pull request on master branch is the preferred way to get contributions. Just be careful to remove long path error only on VS versions where it works.
---
### Author:  [@Thibault](https://discourse.itk.org/u/Thibault)
#### Post date: [February 7, 2020, 4:09pm UTC](https://discourse.itk.org/t/enable-long-path-compilation/2691/3 "2020-02-07T16:09:02Z")
Thanks,
Why isn’t it acceptable to allow it for all Visual Studio since long paths are not supported by default: the developers have to manage GPO? And in the worst case, they will run into the compilation issue with the explicit error from the compiler.
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [February 7, 2020, 4:46pm UTC](https://discourse.itk.org/t/enable-long-path-compilation/2691/4 "2020-02-07T16:46:11Z")
That code is there as a convenience, to prevent a developer for waiting a long time for build to fail. More importantly, with older compiler versions there is no user-friendly error about long path, just a mysterious failure. And this frustration was the reason for adding the CMake code to prevent building.
---
### Author:  [@lassoan](https://discourse.itk.org/u/lassoan)
#### Post date: [February 8, 2020, 5:27pm UTC](https://discourse.itk.org/t/enable-long-path-compilation/2691/5 "2020-02-08T17:27:58Z")
There may be a misunderstanding here. Maximum path length of the _file system_ was never a problem.
Too long paths cause problems in the _build system_ of large projects, as they make intermediate build files or data structures too large. Such limitations exist on all platforms: on MacOSX you get [“malformed mach-o” error if you use too long paths](https://discourse.slicer.org/t/macos-mojave-slicer4-10-install/5126).
---
### Author:  [@Thibault](https://discourse.itk.org/u/Thibault)
#### Post date: [February 11, 2020, 2:12pm UTC](https://discourse.itk.org/t/enable-long-path-compilation/2691/6 "2020-02-11T14:12:25Z")
I am sorry but I don’t connect your point with this issue since you are talking about a MacOSX limitation on another project. The limitation I am pointing out is only applied on Windows toolchain according to the ITK CMakeLists.
```
if( CMAKE_HOST_WIN32 AND NOT ITK_SKIP_PATH_LENGTH_CHECKS )
string( LENGTH "${CMAKE_CURRENT_SOURCE_DIR}" n )
if( n GREATER 50 )
message(
FATAL_ERROR
"ITK source code directory path length is too long (${n} > 50)."
"Please move the ITK source code directory to a directory with a shorter path."
)
endif()
string( LENGTH "${CMAKE_CURRENT_BINARY_DIR}" n )
if( n GREATER 50 )
message(
WARNING
"ITK_SKIP_PATH_LENGTH_CHECKS "
"${ITK_SKIP_PATH_LENGTH_CHECKS}"
)
message(
WARNING
"CMAKE_MATCH_1 "
"${CMAKE_MATCH_1}"
)
message(
FATAL_ERROR
"ITK build directory path length is too long (${n} > 50)."
"Please set the ITK build directory to a directory with a shorter path."
)
endif()
endif()
```
What did I misunderstand?
What is your definition of a large project?
Otherwise, why is the path limitation set at 50?
---
### Author:  [@lassoan](https://discourse.itk.org/u/lassoan)
#### Post date: [February 11, 2020, 2:53pm UTC](https://discourse.itk.org/t/enable-long-path-compilation/2691/7 "2020-02-11T14:53:20Z")
> [@Thibault](#):
>
> What did I misunderstand?
It seems that your assumption is that path length limitation is imposed because of file system limitations. File system limitations rarely the bottleneck. The problem is that build systems on all platforms have limitations on the maximum length of file names, path lengths, etc. regardless of what is the maximum allowed path length on the file system.
> [@Thibault](#):
>
> What is your definition of a large project?
ITK is already a large project by itself, so if you enable building all of its components then you may run into issues that would not occur if you only worked with a few hundred files.
> [@Thibault](#):
>
> Otherwise, why is the path limitation set at 50?
The formula to compute the maximum allowed length from project name (yes, this affects the length of the allowed file name that you can use), folder name, and other parameters depends on the build toolchain version. 50 was a number that seemed to work well for most projects. If you are confident that you won’t have problems due to long paths then disable the check and see if you succeed. If the build is successful then you can use that build tree. Of course it does not mean that the same thing will work on a different computer.
See Microsoft build systems engineers’ take on this issue here: [MSBuild should handle paths longer than MAX\_PATH · Issue #53 · dotnet/msbuild · GitHub](https://github.com/Microsoft/msbuild/issues/53)
---
### Author:  [@Thibault](https://discourse.itk.org/u/Thibault)
#### Post date: [February 11, 2020, 3:43pm UTC](https://discourse.itk.org/t/enable-long-path-compilation/2691/8 "2020-02-11T15:43:07Z")
> [@lassoan](#):
>
> It seems that your assumption is that path length limitation is imposed because of file system limitations. File system limitations rarely the bottleneck. The problem is that build systems on all platforms have limitations on the maximum length of file names, path lengths, etc. regardless of what is the maximum allowed path length on the file system.
You are saying that all platforms have limitations.
Could you explain why is this limitation in place only for Windows?
> [@lassoan](#):
>
> ITK is already a large project by itself, so if you enable building all of its components then you may run into issues that would not occur if you only worked with a few hundred files.
Could you be more specific? I would like to know what is the root cause of the limitation.
What is the maximum number of files supported without limitations?
> [@lassoan](#):
>
> The formula to compute the maximum allowed length from project name (yes, this affects the length of the allowed file name that you can use), folder name, and other parameters depends on the build toolchain version. 50 was a number that seemed to work well for most projects.
It seems that you have no formula and that you accidentally make the toolchain work with a random number without having investigated this issue…
> [@lassoan](#):
>
> If you are confident that you won’t have problems due to long paths then disable the check and see if you succeed. If the build is successful then you can use that build tree. Of course it does not mean that the same thing will work on a different computer.
I have tried and I succeed: see my first message.
> [@lassoan](#):
>
> See Microsoft build systems engineers’ take on this issue here: [MSBuild should handle paths longer than MAX\_PATH · Issue #53 · dotnet/msbuild · GitHub](https://github.com/Microsoft/msbuild/issues/53)
As I have said in my first message, since you have deactivated the compilation for path length \> 50 for Windows ( 2018 Jan) changes have happened → [MSBuild should handle paths longer than MAX\_PATH · Issue #53 · dotnet/msbuild · GitHub](https://github.com/Microsoft/msbuild/issues/53#issuecomment-459062618)
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [February 11, 2020, 4:17pm UTC](https://discourse.itk.org/t/enable-long-path-compilation/2691/9 "2020-02-11T16:17:39Z")
Enabling building of tests is more likely to produce problems. Enabling additional modules (which are OFF by default) can cause problems.
> ## Does that mean things work?
>
> No, for all the reasons detailed in comments above: just because _MSBuild_ works, doesn’t mean _your build_ will, because many other tools are involved.
>
> `devenv.exe` , the main Visual Studio process, does not yet opt into support. That means only command-line builds will be affected by the MSBuild changes.
This is not too encouraging. It works on your computer, but might not on someone else’s computer.
The code singles out the Windows platform, because it is the most restrictive, and the most people use it. The limit of 50 characters was arrived at experimentally. It depends on which modules are enabled, and whether tests are enabled. The length of file names matters, not just the depth of directory hierarchy.
---
### Author:  [@Thibault](https://discourse.itk.org/u/Thibault)
#### Post date: [February 11, 2020, 4:26pm UTC](https://discourse.itk.org/t/enable-long-path-compilation/2691/10 "2020-02-11T16:26:51Z")
Ok, so if someone is succeeding in building all ITK with all additional modules and tests, then this solution should be proposed.
Why is this limitation not related to the activation of these additional modules and tests?
So, currently, with this path length limitation, all additional modules and tests are correctly built on all platforms?
---
### Author:  [@lassoan](https://discourse.itk.org/u/lassoan)
#### Post date: [February 11, 2020, 4:46pm UTC](https://discourse.itk.org/t/enable-long-path-compilation/2691/11 "2020-02-11T16:46:21Z")
> [@Thibault](#):
>
> Could you explain why is this limitation in place only for Windows?
“malformed mach-o” error started to show up not too long ago on MacOSX (due to operating system, build toolchain, or ITK changes) and there has not been enough time to understand and address this issue well enough. Probably path length warning or limitation would be useful for MacOSX, too.
> [@Thibault](#):
>
> I would like to know what is the root cause of the limitation.
> What is the maximum number of files supported without limitations?
I don’t have the answer for this - it depends on number of compilation units, libraries, etc. For example, lots of new issues came in with ITK modularization, even though total number of files did not change.
> [@Thibault](#):
>
> It seems that you have no formula and that you accidentally make the toolchain work with a random number without having investigated this issue…
In recent years, I probably spent tens of hours with debugging issues related to long paths. At some point I ran tens of builds in parallel with different path lengths to collect more data so that I can understand what’s happening. Still, I have no formula. Microsoft published formulae for some older Visual Studio versions but they are not available for more recent versions.
Also, some randomness may be involved in the process, too. Just an example: long paths may cause your environment (where environment variables stored) reach the maximum allowed size. On certain Windows versions, the environment was allowed to grow up to 4x the allowed size, but a single character was removed at each n x 8192th position. Each of these removed characters corrupted a single path. This corruption caused build errors in some cases, while it did not matter in other cases. So, it happened that some build error could be resolved by making the path one character longer, or changing values of some unrelated environment variables. None of these issues happened if path lengths were kept short.
Some issues only come up if you link further libraries into your application. So, if you build a small test application with only ITK, it does not mean that the same thing will work if you link VTK to it as well.
It would be great if you could do your own investigation, with current operating system and build toolchain versions and share the results with us. As a testbed, you can use existing open-source applications that use ITK, such as 3D Slicer or MITK.
---
### Author:  [@Thibault](https://discourse.itk.org/u/Thibault)
#### Post date: [February 11, 2020, 4:59pm UTC](https://discourse.itk.org/t/enable-long-path-compilation/2691/12 "2020-02-11T16:59:40Z")
Ok! Thanks a lot for the clarification!
It makes the issue a way more understandable. I now see how to test the toolchain.
I will try to test all that when I will have more time, because it would be very appreciated for CI purpose.
However I will only test on Windows 10, but with different version of VS.
---
### Author:  [@Mohammad\_Adeel](https://discourse.itk.org/u/Mohammad_Adeel)
#### Post date: [December 27, 2025, 11:11pm UTC](https://discourse.itk.org/t/enable-long-path-compilation/2691/13 "2025-12-27T23:11:54Z")
You can try using a tool like LongPathTool. It helps manage and delete files or folders with long path issues easily.
---
### Author:  [@JackyFlint](https://discourse.itk.org/u/JackyFlint)
#### Post date: [March 5, 2026, 6:30pm UTC](https://discourse.itk.org/t/enable-long-path-compilation/2691/14 "2026-03-05T18:30:21Z")
LongPathTool fixed long path errors that were blocking ITK builds on Windows due to path limits