Windows bundled llama-server.exe is missing `longPathAware`: GGUF paths > 260 chars fail with "No such file or directory" even when the file exists and LongPathsEnabled=1
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 72/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- cmake, cpp
- Domain
- backend, build-system
Research direction
Start by locating the Windows binary manifest and build configuration, including the CMake or linker manifest step mentioned in the issue. Check how the bundled llama-server.exe receives its manifest, then verify that the built executable declares longPathAware and can load a GGUF from a path longer than 260 characters with Windows long path support enabled.
Written by the indexing model from the issue text.
Description
Name and Version
Windows bundled llama-server.exe (x64) shipped with Unsloth Studio; Windows 11 Build 22631, LongPathsEnabled=1
Operating systems
No response
Which llama.cpp modules do you know to be affected?
No response
Command line
llama-server.exe -m "C:\Users\<name>\.cache\huggingface\hub\models--xxx\snapshots\<sha>\...model.gguf" (absolute path > 260 chars)
Problem description & steps to reproduce
Environment
- Windows 11 (Build 22631),
LongPathsEnabled=1(HKLM\SYSTEM\CurrentControlSet\Control\FileSystem) - Unsloth Studio bundled
llama-server.exe(Windows, x64)
Bug / expected behavior
Loading a GGUF whose absolute path exceeds 260 characters fails with failed to open GGUF file ... (No such file or directory), even though the file exists and is readable. Expected: the file should load, since the OS long-path support is enabled.
Steps to reproduce
- Place a valid GGUF under a deep directory so the absolute path is > 260 chars (e.g. a Hugging Face cache path like
C:\Users\<name>\.cache\huggingface\hub\models--xxx\snapshots\<sha>\...model.gguf, 276 chars in our case). - Run
llama-server.exe -m <that path>. - Observe:
error: failed to open GGUF file '<path>' (No such file or directory).
Root cause
The bundled exe's application manifest does not declare longPathAware. Even with the system-wide LongPathsEnabled=1, a process only gets long-path support after its manifest declares <longPathAware xmlns="urn:schemas-microsoft-com:windows:manifest.v3">true</longPathAware>. Without it, CRT/fopen-style path handling falls back to the legacy MAX_PATH (260) behavior and fails with a misleading ENOENT.
We verified:
- The same file opens fine from .NET / PowerShell (
File.OpenRead), which is why the "No such file" error is easy to misdiagnose as a broken/corrupted engine. - A short-path model (158 chars) loads fine on the same build, confirming the engine is healthy.
- Patching the exe in place by injecting
longPathAware=trueinto its RT_MANIFEST (viaUpdateResource) makes the 276-char model load successfully; short-path models remain unaffected.
Suggested fix
Declare longPathAware in the manifest used to build the Windows binaries (e.g. via the linker/mt.exe manifest step or VS_MANIFEST in CMake). Alternatively, normalize model paths with the \\?\ prefix at the file-open layer in llama.cpp (ggml/common), which also covers users who cannot edit the exe manifest.
Impact
Hugging Face cache paths are deep by design (nested models--* / snapshots/<40-char-sha>), so Windows users loading GGUFs straight from the HF cache hit this frequently. A one-line manifest fix in the build config would remove an entire class of hard-to-diagnose load failures.
First Bad Commit
No response
Relevant log output
Logs
- Dominant language
- C++
- Stars
- 132k
- Forks
- 24.6k
- Avg merge
- 2d 1h
- Merged PRs (30d)
- 500
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ggml-org/llama.cpp
-
bug-unconfirmed
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
ggml-org/llama.cpp#31163 · 1 comment ·
Maintainers usually reply within 1 day
-
Misc. bug: docs mention --spec-draft-conf-min, but that flag doesn't existPossibly taken @jajamabhijith claimed this 1 day ago. Openbug-unconfirmed
Difficulty 1/5 Under an hour Newbie friendliness 91/100
Maintainers usually reply within 1 day
-
bug-unconfirmed
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
Maintainers usually reply within 1 day
-
Misc. bug: Metal aborts on MUL_MAT with BF16 src1 at K >= 64, batch > 8 (no BF16 mul_mm kernel)Possibly taken @rashid5925 claimed this 3 days ago. Openbug-unconfirmed
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
ggml-org/llama.cpp#30973 · 4 comments ·
Maintainers usually reply within 1 day
All issues in ggml-org/llama.cpp
Similar issues
-
backlog
Difficulty 1/5 Under an hour Newbie friendliness 91/100
EchoTools/nevr-runtime#1108 ·
Maintainers usually reply within 1 day
-
Status: Needs confirmation Status: Needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
boykopovar/AnyPS5#12124 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
A-combat P-low S-ready-to-start task
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
Maintainers usually reply within 1 day