Long file path issues in Windows 11 Pro with Microsoft VS Code and File Explorer

Anonymous
2022-05-04T22:27:47+00:00

I spent way too long debugging a compile error in MS VS Code (64bit version 1.66.2). It would fail with 'file not found' or 'unable to access file' errors. The workspace is located in "C:\Users\UserName\Documents\My Workspaces\firmware", with several levels of nested source folders below.

Initially, I got several linking errors due to Controlled Folder Access protection using the Ransomware protection built-in to Windows Security. I whitelisted ar.exe and as. exe, but the errors persisted. I even turned off Ransomware protection. Seeing a thread online about long file paths reminded me I hadn't enabled that on Windows 11 yet (fresh install), so I changed the following settings and rebooted the PC:
Registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled set to 1.

Group Policy: System "Configuration>Administrative Templates>System>Filesystem>Enable Win32 long paths" enabled.

About that time I noticed an issue with not being able to delete or rename files on an SMB share that were in a deep path. If I went to the other system and moved them up a few folders I was again able to rename the files.

Both of these scenarios work fine from my Windows 10 Pro PC. My Windows 11 Pro PC is a fresh install (Version 21H2 Build 22000.613).

So I believe Windows 11 isn't respecting my Long Paths settings. As a final test, I moved my VS Code Workspace folder to system drive root (C:\firmware) and it compiled without error.

I've seen other questions on here about Windows 11 path length issues that were brushed away because they were encountered using non-Microsoft 3rd Party software, but this is all built-in File Explorer and Microsoft's own VS Code product.

My question is, how do I actually allow long file paths in Windows 11 Pro?

Windows for home | Windows 11 | Files, folders, and storage

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments

77 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Les Ferch 10,361 Reputation points Volunteer Moderator
    2023-11-19T16:18:28+00:00

    That will make no difference.

    Application manifests are for developers to set certain options for their applications at compile time. They can't be used to change the capabilities of an exe afterwards. Only Microsoft can add long path support to Explorer and they haven't done that yet.

    Explorer only supports navigating long paths. Currently, you have to turn to third parties to get a file manager with full long path support. One such option is Directory Opus.

    Was this answer helpful?

    2 people found this answer helpful.
    0 comments
  2. Anonymous
    2023-10-10T15:48:28+00:00

    My update on this:

    -Windows 11 Enterprise

    -Version 22H2

    -OS Build 22621.2134

    All of the suggestions listed in this thread failed to support LongPaths, including those from Andy Milne2. The suggestion about leaving LongPathsEnabled in Registry alone and setting it in GPEDIT got me down the right path, but ultimately I had to do the following:

    1. Ensure Enable Win32 long paths in GPEDIT is set to Not Configured.
    2. Delete the LongPathsEnabled key from registry. Sign out/sign on or reboot.
    3. Enable Wind32 long paths in GPEDIT. Sign out/sign on or reboot.
    4. Recreate LongPathsEnabled key in registry and manually set to 1. Sign out/sign on or reboot.

    Only after that process did the BAT script example previously shown in these comments work for me and File Explorer could navigate, add, delete, etc past the 300 character mark.

    md o123456789o123456789o123456789o123456789o123456789o123456789o123456789o123456789o1234_ThisIs100bytes

    cd o123456789o123456789o123456789o123456789o123456789o123456789o123456789o123456789o1234_ThisIs100bytes

    md o123456789o123456789o123456789o123456789o123456789o123456789o123456789o123456789o1234_ThisIs200bytes

    cd o123456789o123456789o123456789o123456789o123456789o123456789o123456789o123456789o1234_ThisIs200bytes

    md o123456789o123456789o123456789o123456789o123456789o123456789o123456789o123456789o1234_ThisIs300bytes

    cd o123456789o123456789o123456789o123456789o123456789o123456789o123456789o123456789o1234_ThisIs300bytes

    md o123456789o123456789o123456789o123456789o123456789o123456789o123456789o123456789o1234_ThisIs400bytes

    cd o123456789o123456789o123456789o123456789o123456789o123456789o123456789o123456789o1234_ThisIs400bytes

    Was this answer helpful?

    2 people found this answer helpful.
    0 comments
  3. Anonymous
    2023-06-11T07:54:07+00:00

    Hi guys, I may have the trick.

    I'm on Win11 22H2, build 22621.1778.

    Enabling the Win32 long paths via gpedit alone not solve the issue if you're using Windows Explorer.

    TL;DR

    But just use 7-zip (as the file explorer) to move the files/folders does the trick, hope this helps you all.

    Was this answer helpful?

    2 people found this answer helpful.
    0 comments
  4. Anonymous
    2023-01-23T17:31:35+00:00

    Thanks Pratik: You inspired me to bang away at this issue again. I have now, on my windows 11 box, successfully created a folder over 400 bytes deep!

    Here's the steps:

    make a .BAT file with the following contents:

    md o123456789o123456789o123456789o123456789o123456789o123456789o123456789o123456789o1234_ThisIs100bytes

    cd o123456789o123456789o123456789o123456789o123456789o123456789o123456789o123456789o1234_ThisIs100bytes

    md o123456789o123456789o123456789o123456789o123456789o123456789o123456789o123456789o1234_ThisIs200bytes

    cd o123456789o123456789o123456789o123456789o123456789o123456789o123456789o123456789o1234_ThisIs200bytes

    md o123456789o123456789o123456789o123456789o123456789o123456789o123456789o123456789o1234_ThisIs300bytes

    cd o123456789o123456789o123456789o123456789o123456789o123456789o123456789o123456789o1234_ThisIs300bytes

    md o123456789o123456789o123456789o123456789o123456789o123456789o123456789o123456789o1234_ThisIs400bytes

    cd o123456789o123456789o123456789o123456789o123456789o123456789o123456789o123456789o1234_ThisIs400bytes

    run that and it works fine on my windows 11 boxes. That .BAT works great from either cmd console and powershell console.

    However, my original powershell script still fails. I suspect that the issue is relative pathnames and UNC. i.e. for long path support the OS really likes "\?" at the beginning of the filename. My original script was using "./" or "." at the beginning, and that prefix might mess up windows 11 - whereas windows 10 handles it fine.

    Now that I managed to create some long paths, I went ahead and tested my long path aware application and it works great with these deep paths!

    So, my takeaway from all this:

    a) To enable long paths: use the group policy technique: Local Computer Policy, Computer Configuration, Administrative Templates, System, Filesystem, Enable Win32 long paths, set this to Yes, and then reboot.

    b) avoid relative pathnames in scripts.

    Thanks again Pratik for proving us all wrong here, and that we can have deep folders in windows 11.

    Was this answer helpful?

    2 people found this answer helpful.
    0 comments
  5. Anonymous
    2022-12-02T18:29:08+00:00

    I actually talked with Microsoft yesterday. Apparently they needed more info before they were willing to attempt to reproduce the issue.

    So, I ran a few scripts that they gave me on a clean and fully patched Windows 11 VM. Gave them those logs and now they're looking into whether they can reproduce the issue at their end.

    Hopefully they'll make their reproduction attempt soon...

    Awesome! Really hope they recognize it as a bug and fix in a cumulative update or something. It is starting to get in my way as I migrated over to Windows 11.

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments