This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
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?
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.
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.
The above script worked for me on my Windows 11 Pro 22H2.
But I am still not able to close this repository due to Long path errors https://github.com/kiegroup/drools-wb
Used the same two steps enabled group policy and then LongPathsEnabled to 1.
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
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.
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.