Loading today’s stories
Build1 distinct publisher3 min readUpdated
A team trimmed every folder name in an Unreal Engine 5 project and cook still died at 260 characters. The fix was long-path support on the runner, plus a restart and a verified artifact.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A team packaging an Unreal Engine 5 project did the obvious thing first: copied the project to a very short build root, trimmed folder names, kept the packaging workspace deliberately shallow, and cook still failed [1]. According to the write-up on dev.to, the fix that restored the build was not more shortening but Windows long-path support on the build machine [3].
The failure signature was the familiar pair: "Couldn't save package, filename is too long (... >= 260)" followed by "AutomationTool exiting with ExitCode=25 (Error_UnknownCookFailure)" [2].
The reason a short root is not sufficient is that packaging does not write to the path you see in the Content Browser. Cook and staging wrap their own directory structure around it, producing something on the order of `<short-root>\Saved\Cooked\Windows\<project>\Content\<nested-asset-path>` [4]. Count the literal characters in that scaffold and you get 31 before the project name is even substituted in [20]. Against the legacy 260-character ceiling, that leaves 229 characters to be shared by the drive root, the project name and the asset path itself [21]. Deep asset folders, duplicated import directories, generated names, plugin content and the cook output structure all spend from the same budget [5]. Moving a project into a path like `E:\u\work` reduces risk without guaranteeing the destination stays inside MAX_PATH [5].
The OS side has two requirements, per Microsoft's documentation as cited in the post: the system setting `LongPathsEnabled` must be `1`, and the application must declare itself `longPathAware` [6]. The team set the registry value under `HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem` from an elevated PowerShell session with `New-ItemProperty`, then read it back with `Get-ItemPropertyValue` to confirm the effective value was `1` [7][8]. The same thing is available through Group Policy at Computer Configuration > Administrative Templates > System > Filesystem > Enable Win32 long paths [9]. After that configuration was applied, packaging returned to normal with the longer asset paths intact [10].
The trap worth internalising: Windows caches that registry value per process once an affected filesystem function has been called, so changing the key and immediately retrying inside a running Editor, AutomationTool, build agent or sandbox service can reproduce the identical error [11]. Restart the affected UE and UAT process tree; for a machine image or a persistent runner, reboot [12].
Enabling the flag also only lifts the limit for executables that opt in, and a packaging chain includes several binaries, plugins, archive utilities and scripts, any of which can still assume 260 characters [13]. If the error survives a clean restart, the post's triage is by layer: an executable that is not long-path-aware, an explicit length check in your Unreal version or configuration, a third-party cooker or archiver, or project content that is simply too deeply repeated [14]. Short paths remain reasonable hygiene, especially where a tool's long-path behaviour is unknown, but they should not paper over a misconfigured runner [18]. For content cleanup, move or rename assets inside the Editor and fix redirectors rather than renaming `.uasset` files in File Explorer [15].
Watch how you close the loop. An API response saying "job started" is not packaging proof, and neither is the absence of the first long-path message [16]. Keep the deeply nested asset that reproduced the failure, re-run the same `BuildCookRun`, confirm Cook and AutomationTool both complete, and confirm the staged or archived artifact actually exists on disk [17].
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
Shortening paths further was useful as a defensive measure but was not the fix that restored the build; the missing piece was Windows long-path support.
After the Windows configuration was applied in the build environment, the Unreal packaging flow returned to normal with the longer asset paths intact.
The Unreal Engine 5 project was copied to a very short build root, folder names were trimmed and the packaging workspace was deliberately shallow, and cook still failed.
Cook failed with the pair of messages: "Couldn't save package, filename is too long (... >= 260)" and "AutomationTool exiting with ExitCode=25 (Error_UnknownCookFailure)".
Unreal packaging does not operate only on the path visible in the Content Browser; cook and staging add their own directory structure, so a source asset can become something like <short-root>\Saved\Cooked\Windows\<project>\Content\<nested-asset-path>.
Deep asset folders, duplicated import directories, generated names, plugin content and Cook's output structure all spend characters from the same length budget, which is why moving a project into a path such as E:\u\work can reduce risk without guaranteeing success, since the generated destination can still cross the legacy MAX_PATH boundary.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Specific and checkable, but single-source and unreplicated
The account supplies verbatim error strings, an explicit cook-output path template, exact PowerShell commands and registry key, the Group Policy location, and a five-step verification protocol — all independently checkable against Microsoft's documented long-path requirements. What is missing is any second observer: no engine or OS version, no logs, no artifact hashes, and no third-party reproduction of the causal claim that the registry change is what restored packaging.
One disclosed team environment
Adoption evidence is limited to the author's own build environment: LongPathsEnabled applied on their UE runners and a described layered runner policy. There is no fleet size, no other organisation, and no usage telemetry. The underlying Windows setting is widely available, but the sources do not measure how broadly it is enabled across Unreal build pipelines.
Slightly overstated framing, well-hedged body
The framing generalises one environment into a rule ('the real fix' is a Windows setting), which outruns a single unreplicated incident where short roots were also retained. The body pulls the other way with unusual restraint: it keeps short paths as hygiene, warns that the registry value only helps opt-in executables, lists four possible rejecting layers, and refuses to treat a 'job started' response or a missing error line as proof. Net gap is small and positive.
Disclosed promotional context around genuine debugging content
The post is a contest submission to DEV's Summer Bug Smash 'powered by Sentry' and closes with a disclosure that the author works on SEELE AI plus a link to that product's Unreal game-creation page. Those are visibility and lead-generation incentives, and they are disclosed rather than hidden. Nothing in the technical remediation depends on buying a product — the fix is a free OS setting — which caps the distortion risk.
Moderate: mechanism solid, incident evidence thin
Confidence is split. The documentation-grade layer (Microsoft's two requirements, registry and Group Policy locations, per-process caching semantics, opt-in scope) is well specified and checkable, and the derived path arithmetic follows directly from the published template. The incident-specific causal claim is single-source, first-party, commercially disclosed, unreplicated, and reported without engine/OS versions or artifacts — so the operational lesson is more trustworthy than the attribution.
build
Four indexes, none of them covering: the 78-second page and the one index that fixed it1 distinct publisher
build
The fence was fine, the test was green, and the injection still worked1 distinct publisher
build
Codex learns to click: the coding agent stops typing patches and starts operating the machine1 distinct publisher
build
A Prometheus that had written nothing for hours passed every health check1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 21, 2026