Path length limitation in Windows lifted

Engineering
1

With a recent version of Windows 10, paths longer than 260 characters can be enabled. But we need to account for that possibility in ITK in order to take advantage of it.

1 Like
2

I guess this is related to this: When installing Python (at least the latest version) on Windows, there is an option to “Disable path length limit”.

3

Patch and commit for the fix.

4

Total file path length of 32k characters have been available in Windows for many years (using in Unicode API, on NTFS disks), but MSBuild and other build tools have not been updated to take advantage of this.

In Windows10, probably it’ll be easier to update the tool chain to support longer file paths, but it is still probably a lot of work, so it is not likely to happen anytime soon. As you can see in this discussion, the developer team is quite reluctant to work on this (but there is hope): https://github.com/Microsoft/msbuild/issues/53

Also note that not only file paths but command line and environment size are limited, too. They impose limits on maximum file path lengths, too.

As a conclusion, I don’t think we can disable file path length checks just yet (regardless of LongPathsEnabled registry setting).

5

The registry key for disabling path length limitation is off by default. Since this patch, the setting becomes visible for Windows versions on which the limit can be disabled. But user has to explicitly opt in, at least for now. Microsoft might change that in the future, once all the relevant tools get upgraded to work without issue with longer paths.

Without this option, there was no way to build ITK and projects which have it in its super-build (e.g. Slicer) in a longer path.

6

@lassoan Thanks for the interesting link. Out of curiosity, have you had a chance to test Slicer with this ITK patch?

7

Do you mean enabling long path support in Windows 10, disabling path length check in ITK, then trying to build Slicer in a long path?

8

I tried it with patched ITK, and in some long build path. It failed - I don’t remember the exact reason. It was not ITK-related.

9

Indeed, that is what I was suggesting, but I guess there is no point to try if ITK doesn’t compile in a long path as @dzenanz just explained.

10

I guess first we should just try if ITK can be built reliably in long paths. Have you checked that? In what paths exactly? With what Visual Studio version?

Note that long paths can cause environment size corruption/truncation, too - if you pass file paths via command-line arguments (see for example https://github.com/commontk/CTK/issues/525).

11

It was using VS2015. The path was long, it didn’t have special characters in it (e.g. ž) or spaces. Post here.

12

I assumed too fast that this had been tested for ITK. I just checked with Windows10/Visual Studio 2017, and LongPathsEnabled set to 1, with ITK source and build directory in a long path (directory with about 150 characters in its name), and multiple errors arise:

  1. At cloning time, git complains with errors like this one:
error: unable to create file Modules/Core/ImageFunction/include/itkVectorLinearInterpolateNearestNeighborExtrapolateImageFunction.hxx: Filename too long
  1. At configuration time, I get errors like this:
Data file referenced by argument

DATA{Baseline/itkMagnitudeAndPhaseToComplexImageFilterTestBaseline.mha}

corresponds to source tree path

Modules/Filtering/ImageIntensity/test/Baseline/itkMagnitudeAndPhaseToComplexImageFilterTestBaseline.mha

that does not exist as a file (with or without an extension)!
Call Stack (most recent call first):
CMake/ExternalData.cmake:485 (_ExternalData_arg)
CMake/ExternalData.cmake:324 (ExternalData_expand_arguments)
CMake/ITKModuleTest.cmake:127 (ExternalData_add_test)
Modules/Filtering/ImageIntensity/test/CMakeLists.txt:315 (itk_add_test)
This warning is for project developers. Use -Wno-dev to suppress it.
  1. At generation time, I get:
CMake Error at Modules/ThirdParty/GDCM/src/gdcm/Source/DataStructureAndEncodingDefinition/CMakeLists.txt:87 (add_library):
Cannot find source file:

gdcmUNExplicitImplicitDataElement.cxx

Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx
  1. When trying to open Visual Studio project, I get:
The operation could not be completed. The filename or extension is too long.

So there are indeed a lot of problems to overcome before this is usable.

1 Like
13

In practical terms, the path limit is higher with LongPathsEnabled set to 1. But it also probably depends on other pieces of the puzzle (CMake, VisualStudio, git etc). Could you try to figure out the new limit @fbudin?

14

FYI, the problem with git clone can be solved by running git config --system core.longpaths true beforehand (here). This also solves the CMake configuration and generation errors.

2 Likes
15

EDIT: Disabling the tests allowed me to successfully compile ITK with VS2017 and VS2013 (I do not have VS2015 to test)

As a final step, I tried to compile ITK with VS2017 (Windows 10): After reducing the path of the build directory to 69 characters to avoid the error mentioned above:

I was able to open Visual Studio, start the build, and I now get 5 failures (still due to the path being too long). So I think for now there is no way to work around the 260 characters limitation.

Disclaimer: I did not try any other path sizes than the ones mentioned in my posts (140 and 69).