Unity Editor still hits Windows MAX_PATH (260 char) limit even with LongPathsEnabled — any real fix?

Unity Engine
, , ,
1

Unity Editor still hits Windows MAX_PATH (260 char) limit even with LongPathsEnabled — any real fix?

Hi everyone,

I’m running into the classic Windows path length problem while working on a project with a fairly deep folder structure (nested Scope-based architecture under Assets, e.g. ProjectScope/SceneScope/SceneVariants/…/PublicContracts/SomeName.asmdef).

When the full path exceeds 260 characters, I get:

DirectoryNotFoundException: Could not find a part of the path “…long path here…asmdef”

I’ve already tried the standard Windows fix:

  • Enabled LongPathsEnabled (DWORD = 1) under HKLM\SYSTEM\CurrentControlSet\Control\FileSystem
  • Rebooted
  • Set git config --system core.longpaths true

This is the documented way to lift the 260-char MAX_PATH restriction on Windows 10/11, and it works for many modern apps that are compiled with the longPathAware manifest. However, it does NOT fix the issue in the Unity Editor — the error still happens.

My understanding is that Unity Editor’s own file I/O (and possibly parts of the underlying .NET Framework/Mono runtime it uses) isn’t compiled with long-path awareness, so the registry flag is simply ignored by Unity regardless of OS-level settings.

Questions for the community / Unity devs:

  1. Is this a known limitation of the current Editor build, or is there a newer Unity version/runtime (e.g. under .NET Core-based scripting backend) where this has actually been fixed?
  2. Is there an official bug report / roadmap item tracking Win32 long path support in the Editor?
  3. Aside from workarounds like subst/mklink junctions or keeping the project close to the drive root, is there any supported way to get Unity to respect long paths on Windows?

Would appreciate any insight from people who’ve hit this with deep nested asmdef/DI-scope structures. Thanks!

2

Yes, and you can expect for this NOT to go away. It’s not just Unity Editor. There’s all the compiler toolchain with a gazillion of tools not created by Unity which would have to support that.

I get the immediate feeling this is an over-engineered folder structure that just needs an overhaul to stay well within the “sane” limits. No offense, we’ve all been there once or twice. :wink:

3

It’s just very strange that such a limitation still exists in the modern world. I understand your assumption about an over-engineered folder structure, and I can easily fix that issue in my own case. I was just curious to know in general, and for the future: hitting this limitation doesn’t necessarily mean the structure is over-engineered — maybe for convenience I want to mirror the scene hierarchy as folders, maybe I want to split nested DI scopes across folders in some particular way, and that ends up needing a longer path? The very idea that a 260-character limit is the only reason to restructure your architecture sounds absurd.

4

depending on where your top folder is you can substitute a chunk of the path with

subst d: c:\\users\\me\\documents\\dev\\path

5

As CodeSmile said, this limitation isn’t going to go away anytime soon due to the sheer number of external tools Unity depends on. I believe engine’s own code should handle long paths just fine but as soon as you start dealing with various compilers and other tools, things start exploding.

6

No Sh.., bro! :laughing:

Excuse the language but yes, totally agree. My personal pet peeve is this:

You see, that’s a blank space character. When you put that anywhere, even within the path leading up to a project, wiiiiiiiiiild things can happen.

Not to mention all those other weird characters to have in paths and filenames. Be it ä or ô or ß or + and not to mention uni-eewwww-code characters! Those are the downfall of many tools and applications.

I wish we still had 8.3 filenames, ASCII only. It would be a better tooling world for sure. But a terrible one for mankind. :face_with_peeking_eye:

7

That bit is getting better. For a few years now I’ve been adding spaces and emojis to my Windows username, which makes C:\Users\<USERNAME> have those characters. There’s only one thing that reliably breaks with it: the Android SDK.

8

I do wish they would improve long path name support when loading addressables - builds end up having to be installed in shorter named base paths under C:/ just to save enough characters to load bundles that have longer paths like C:/<path_to_bundles>/<bundle_uuid>/<version>/<platform>/<filename>.bundle