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: Newest
Most helpful Newest Oldest
  1. Anonymous
    2023-01-25T13:53:12+00:00

    It doesn't seem to work for any version of Windows 11, be it Pro, Education or Home

    Was this answer helpful?

    0 comments
  2. Anonymous
    2023-01-23T17:55:42+00:00

    addendum: native powershell stuff is still broken. But, running a .BAT from powershell appears to handle long paths ok. (I suspect it launches cmd console to process the .BAT)

    So, new theory: Just powershell in windows 11 is broken for long paths. Win10 powershell works great with long paths.

    win11 powershell wont tab complete long pathnames, whereas win10 powershell does. So perhaps Microsoft just goofed up the powershell manifest.

    Was this answer helpful?

    0 comments
  3. 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
  4. Anonymous
    2023-01-22T13:05:26+00:00

    This thread has just broken me...... I have recently deployed 130 W11 laptops and migrated to Sharepoint Online. We are hitting this issue all over the place (after the business decided to change their file structure).

    If you get any updates to this I am super keen to hear about them as I am currently scratching my head on how to resolve this problem.

    Though, from how I'm reading it ... they've pretty much just told us 'go fish'.

    And in your case ... there's probably very few options other than 'ditch OneDrive' to sync your SP (always opening the files from the SP site) or 'ditch WinOS' all together.

    Was this answer helpful?

    0 comments
  5. Anonymous
    2023-01-22T10:42:55+00:00

    It worked I was missing a configuration for Git to enable long paths on it.

    Here is the configuration if anyone else stumbles upon same issue

    git config --system core.longpaths true

    Was this answer helpful?

    3 people found this answer helpful.
    0 comments