Repository navigation
Should support filename longer than 260 characters #1900
Description
Well, I can see that it is a limitation from Microsoft Windows.
But MSDN suggests that this limitation may be removed.
Enable Long Paths in Windows 10, Version 1607, and Later
And there are cases we have to use long paths (when handling some really complicated 3rd-party projects).
Maybe ninja could only raise a warning, but do not stop the build, like cmake does?
Reacted by Maxime Tournier, Zhuo Zhang, Max Golovanov, Serge, Ivanov Sergei, Jordan Williams, Alexandre Bique, Maciej Matuszak, Márton Marczell, Mikael Ek and 16 more
Activity
jhasse commentedon Dec 21, 2020
Duplicate of #1514.
jhasse commentedon Dec 22, 2020
#1514 was removed by GitHub because the user who created it was banned or something. No idea why they won't simply remove his posts only ...
Anyway, I will reopen this one then. #1514 can still be accessed via the GitHub API: https://api.github.com/repos/ninja-build/ninja/issues/1514/comments
jhasse commentedon Feb 22, 2021
https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation
LDong-Arm commentedon Jun 17, 2021
Hi @jhasse,
From the page you linked, the user needs to edit the registry to enable long path support, and also the application needs to declare it in its own manifest (pasted from that page):
Presumably adding this to ninja.manifest should work? Or how would this impact compatibility with old Windows?
Thanks.
LDong-Arm commentedon Jun 17, 2021
Oh #1939 already does that actually.
Add longPathAware manifest to enable long paths on Windows
Add longPathAware manifest to enable long paths on Windows
emmenlau commentedon Apr 6, 2023
So, what are the next steps for this issue?
parbo commentedon Apr 21, 2023
RealDiskInterFaceuses posix file functions like fopen, and also the *A versions of win32 calls, while the long paths page says only *W versions are affected. Another option might be to prepend\\?\, but this only works for absolute paths.parbo commentedon Apr 21, 2023
I made a PR: #2289
25 remaining items
digit-google commentedon Oct 17, 2024
Can you provide exact reproduction steps so we can verify that ourselves (and verify the Ninja version being used too)?
SidneyLann commentedon Oct 20, 2024
Sculas commentedon Oct 20, 2024
You're running Ninja 1.10.2, correct? This issue has been fixed in v1.12.0 (get the latest version here).
Make sure you actually have long paths enabled in Windows as well, as this obviously doesn't work without that.
@SidneyLann Next time though, please read the issue comments before you post your own comment saying a version from 4 years ago doesn't work. Numerous fixes have been posted here already, and it was even closed with a "fixed in 1.12.0" comment.
Lastly, it seems your reproducer project is missing the React Native workaround specified here: #1900 (comment)
The Android SDK includes an old version of Ninja, which it uses by default unless you use that workaround (see comment for info).
(@carrot93 make sure you've done this as well if your project is also React Native!)
sylque commentedon Jan 3, 2025
The provided workaround (#1900 (comment)) doesn't work for me. I get the error even with the Windows fix, the new
ninja.exeinstalled inc:\ninja, and the modifiedbuild.gradle:The new
ninja .exeis installed and used: if I rename c:\ninja to c:\ninja2, the build fails, complaining it cannot foundninja.exe. But, as you can see above, it seems the old (default)ninja.exeis still called at some point.Moving my project closer to the root of my drive solves the issue.
EDIT: I ran "npx expo prebuild --clean" and "gradlew clean" but it didn't solve the issue.
EDIT2: replacing the old
ninja.exeby the new one in its own folder solves the issue.h1nson commentedon Sep 9, 2025
Download the latest Ninja release from the official repository$SDK_PATH$ \cmake$CMAKE_VERSION$\bin with the newly downloaded version
Replace the existing ninja.exe in
panther7 commentedon Sep 24, 2025
@h1nson Same issue with ninja 1.13.1
fr1g commentedon Oct 17, 2025
well, seems on my side, those arguments are not working at all. the output from my console belike:
CMake Warning in CMakeLists.txt: The object file directory K:/DevRepos/ZenChatty/front.rn/node_modules/.pnpm/react-native-worklets@0.5.1_e3492a94937dc0364f467377c0427388/node_modules/react-native-worklets/android/.cxx/Debug/49i85w6f/arm64-v8a/CMakeFiles/worklets.dir/./ has 210 characters. The maximum full path to an object file is 250 characters (see CMAKE_OBJECT_PATH_MAX). Object file K_/DevRepos/ZenChatty/front.rn/node_modules/.pnpm/react-native-worklets@0.5.1_e3492a94937dc0364f467377c0427388/node_modules/react-native-worklets/Common/cpp/worklets/AnimationFrameQueue/AnimationFrameBatchinator.cpp.o cannot be safely placed under this directory. The build may not work correctly. ninja: error: manifest 'build.ninja' still dirty after 100 triesthis stuff still refuses the arguments you mentioned (or, maybe this is not passed-in on my machine)
my ninja version is 1.13.1
fr1g commentedon Oct 17, 2025
this stuff is really annoying... what to blame and who to blame? pnpm, ninja, rn, windows -- these are four holes on a cheese :((((((
anyway, I'm switching to yarn...
MOHAMED-LAAGUILI commentedon Oct 23, 2025
@fr1g no shiiit im already sweating here with build on android some errr with expo and mmkv turbo modules and new arch bla bla
jerinho commentedon Dec 16, 2025
and you think you're not? it make no sense at all to have a long file name. it's file name not file content
biergaizi commentedon Dec 25, 2025
@fr1g As a matter of public records, the error message you posted:
The object file directory has 210 characters. The maximum full path to an object file is 250 characters (see CMAKE_OBJECT_PATH_MAX). Object file
ninja: error: manifest 'build.ninja' still dirty after 100 tries
They are two unrelated error message that has nothing to do with each other. The first is a CMake warning which says it's possible that Ninja won't work correctly - but it's a warning, not an error, and doesn't prevent a build. Instead, the second error is a different a file timestamp problem, usually caused by system clock changes.
Problem 1: File Path
If you have a file path length problem, the build should start successfully, and crash later in the middle at the affected files. A real crash looks as follows:
CMake warning first:
Start the build regardless, and much later in the build, it crashes
In fact some patched Ninja versions may even build the project successfully in spite of the warning.
I've personally noticed an extremely unusual behavior: when building Qt6, the
ninjashipped in "Visual Studio 2022" raises this warning, but it may still work if your file path is long but not too long. One extra directory is enough to break the build.Problem 2: File Timestamps
The second message is the real error, it says CMake has tried running Ninja 100 times, but Ninja always reports the manifest as dirty, this is tracked by #1599. Like many build systems, Ninja use the file timestamps to determine which file of object code is outdated. So a common root cause is when your system clock has been changed after building some files, as a result, some object code may contain timestamps from the future, and Ninja will always see outdated outputs, because it expects the timestamps are always from the past.
To fix the second problem, delete all existing build outputs, temporary files and object code to restart from scratch with clean file timestamps. Alternatively, you can reset the timestamps of all build outputs and object code using PowerShell.
Don't use the
-Fileargument because both files and directories must have their timestamps reset.Sometimes, even deleting the build directory is not enough. The source code directories must also be restarted from scratch. You may also need to purge all dependencies as well, if those files provide
.cmake. You may need to hunt for timestamps in your entire filesystem. Sometimes, thecmakeor Visual Studio installation itself inProgram Filescan also be the problem, because they provide.cmakefiles (see below)!In my case, my source code directory's timestamp was 5 PM while the system clock was 1 PM.
But it was still broken, I eventually invoked ninja manually at the affected directory using
-d explainto debug:Gotcha. The broken timestamp is located under
C:/Program Files (x86)/Microsoft Visual Studio/2022/BuildTools/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/.To fix Visual Studio's CMake installation:
If your CMake is installed using a different method, the paths will differ. The most reliable diagnosis is to use
ninja -d explainunder the affected build directory to see the root cause. But if the build is triggered by some complicated wrapper script or IDE, it may not be possible. In this case, hunting the entire computer's filesystems C:, D:\ may be the only feasible option...amo-si commentedon Mar 12, 2026
Anybody managed to make it work in WSL?
I added the modified snippet
externalNativeBuild { cmake { arguments "-DCMAKE_MAKE_PROGRAM=/mnt/c/ninja/ninja", "-DCMAKE_OBJECT_PATH_MAX=1024" } }Since the actual executable lives in Windows and is a .exe, I created the symlink in WSL
ln -s "/mnt/c/ninja/ninja.exe" "/mnt/c/ninja/ninja"but I'm still missing something,I get the error
Sculas commentedon Mar 13, 2026
@amo-si Try installing the Android SDK in WSL and using that. No matter what you do, you can't use Ninja from Windows with a project inside WSL, since CMake doesn't know it needs to specify a UNC path for that to work (it doesn't and causes that error you see).
I've personally found out that Android development with WSL is a bit of a painful experience because you need the Android SDK on Windows as well for the emulator, and then using ADB to connect them. I'm not sure if it's improved over the past few years; I hope it has. Hopefully, this solves your issue!
hoang-mai commentedon Apr 21, 2026
i follow the instruction, but it doesn't work, i think the cause is that I use pnpm instead of npm . Anyone can help me please huhu!!!
Add longPathAware manifest to enable long paths on Windows