We Shortened Every Path in Our Unreal Build. That Wasn’t the Real Fix.

This is a submission for DEV's Summer Bug Smash: Smash Stories, powered by Sentry.

We had already done the obvious thing.

The Unreal Engine 5 project was copied to a very short build root. Folder names were trimmed. The packaging workspace was deliberately shallow.

Cook still failed with the familiar pair:

Couldn't save package, filename is too long (... >= 260)
AutomationTool exiting with ExitCode=25 (Error_UnknownCookFailure)

Our first response was to shorten paths even more. That was useful as a defensive measure, but it was not the fix that restored the build. The missing piece was Windows long-path support.

This post explains why a short project root may still be insufficient, what we changed, and how to verify the result without mistaking a started job for a successful package.

Why the short-root workaround was convincing

Unreal packaging does not operate only on the path you see in the Content Browser. Cook and staging add their own directory structure around it. Conceptually, a source asset can become something like:

<short-root>\Saved\Cooked\Windows\<project>\Content\<nested-asset-path>

The project root is only one part of the total length. Deep asset folders, duplicated import directories, generated names, plugin content, and Cook's output structure all spend characters from the same budget.

That is why moving a project from a long workspace into a path such as E:\u\work can reduce risk without guaranteeing success. The generated destination can still cross the legacy MAX_PATH boundary.

Short paths remain good build hygiene. They are especially useful when your pipeline includes tools whose long-path behavior is unknown. But they should not hide a misconfigured Windows runner.

The Windows setting that changed the outcome

On modern Windows, long paths are not simply enabled for every process by default. Microsoft documents two requirements:

1. The system setting LongPathsEnabled must be set to 1.
2. The application must declare itself longPathAware.

We enabled the system side from an elevated PowerShell session:

New-ItemProperty `
  -LiteralPath 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' `
  -Name 'LongPathsEnabled' `
  -PropertyType DWord `
  -Value 1 `
  -Force

Then we verified the effective registry value:

Get-ItemPropertyValue `
  -LiteralPath 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' `
  -Name 'LongPathsEnabled'

The expected output is:

1

You can also configure the equivalent policy through Group Policy:

Computer Configuration
  > Administrative Templates
  > System
  > Filesystem
  > Enable Win32 long paths

After this Windows configuration was applied in our build environment, the Unreal packaging flow returned to normal with the longer asset paths intact.

Restarting is part of the change

There is an easy trap here: Windows caches the registry value per process after an affected filesystem function is first called.

If Unreal Editor, AutomationTool, a build agent, or a long-running sandbox service was already running, changing the registry and immediately retrying inside the same process tree may produce the same failure.

Restart the affected UE/UAT and worker processes. For a machine image or persistent build runner, rebooting Windows is the clearest way to remove ambiguity.

Why this is not a universal one-line fix

LongPathsEnabled=1 removes the OS-side limit only for applications that opt in. A packaging chain can include several executables, plugins, archive utilities, and scripts. Any one of them may still impose its own limit.

If the same error remains after a clean restart, check which layer is rejecting the path:

• Windows/API boundary: the executable is not long-path-aware.
• Unreal validation: your UE version or configuration still performs an explicit length check.
• Plugin or third-party tool: an intermediate cooker, archiver, or file library still assumes 260 characters.
• Project content: deeply repeated folders or generated filenames make the pipeline unnecessarily fragile.

At that point, shortening paths is still a valid compatibility fallback. For durable content cleanup, move or rename assets inside Unreal Editor and fix redirectors. Do not rename .uasset files directly in File Explorer.

How we verified the real fix

A successful API response that says "job started" is not packaging proof. Neither is the absence of the first long-path message.

The useful verification sequence is:

1. Keep the original deeply nested asset that reproduced the failure.
2. Enable the Windows policy and restart the relevant process tree.
3. Run the same BuildCookRun path again.
4. Confirm Cook and AutomationTool complete successfully.
5. Confirm the staged or archived build artifact actually exists.
6. If your pipeline uploads the artifact, verify that stage separately.

This matters because long-path failures often create secondary messages such as missing Cook content. Fixing the first path error should remove the downstream symptoms, but only the final artifact proves that the whole packaging chain recovered.

What we kept after the incident

We did not abandon short build roots after enabling long paths. We kept them as a low-cost safety margin for plugins and external tooling.

The resulting policy is deliberately layered:

• Enable Windows long-path support on every UE build runner.
• Restart or rebuild runners after changing the setting.
• Keep temporary packaging roots shallow.
• Avoid needless directory duplication in imported assets.
• Test the complete Cook, stage, archive, and upload path.

The lesson was not "path length no longer matters." It was that shortening every folder is not a substitute for configuring the operating system that runs the build.

Further reading

• Microsoft: Maximum Path Length Limitation
• UE development notes covering the same class of long-path issue

Disclosure: I work on SEELE AI, and this post comes from maintaining an Unreal packaging workflow. If you want to see the Unreal game-building workflow behind that work, here is the SEELE AI Unreal game creation page.

What fixed your worst UE packaging path failure: a shorter root, Windows policy, an Unreal setting, or asset cleanup?