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

After a few months of this, and opening a Microsoft trouble ticket, I found the issue and the solution:

The registry change is not the way to enable long paths with windows 11. Use the GPEDIT technique you described:

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

The above also sets that registry key too, so you only need to do the Group policy change. This gives you as much long path support that Win10 had/has. With one exception: ISE PowerShell. Even though Win11 has a long path enabled manifest for the ISE PowerShell EXE, it does not appear to honor it. No idea why it doesn't work, but ISE is now being phased out, so probably not a good plan to use that console any more.

Win10 and Win11 do have their limitations regarding long path names:

1. filenames are limited to 256 bytes (and yes, some unicode chars count as multiple bytes
2. folder names are limited to 256 bytes.
3. If you do the math, and you want a 32K long path, that's at least 128 deep folder structure. I've made a few of these on my win11 box and it's not pretty. You'll run into all sorts of issues with explorer and the command console. These issues are common to both Win10 and Win11, so Windows 11 is just as good at long paths as Windows 10. (except the ISE console)

I ported my application to use long paths and it works great on Win10 and Win11. I had to switch command line parameters to response files because the command line is also limited to 32K bytes. (i.e. can't pass a long filename AND parameters, 2 long filenames are right out!). The Win32 APIs that support 32K path names are very limited and do require you use UNC and unicode versions of the names.

Microsoft have a long way to go with regard to proper support of long filenames. I'd like to see the 256 byte limitations above removed, and command line length increased by at 10X or more. Obviously explorer.exe needs to support long names (but, attempting to display a 32K filename on a single screen is rather challenging - and virtually impossible to use within the debugger (since strings are typically only allowed a single line).

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.

I have an update from Microsoft! But, you're not going to like it....

They told me to try that Group Policy thing:

"Can you please check with the Group Policy for the long path enabled, which is present over

System Configuration>Administration Template>System>File System then please select enable longs path to open it."

But, the good news, they also said: "We have checked the same at our end and it's having the same scenario."

So, it's possible that they've reproduced the issue. I've asked for clarification, and pointed out that the group policy thing didn't work.

It's unfortunate that the VM I ran their logging stuff on used the registry setting trick to enable long path support. Turns out that if you go with the group policy trick then that'll also set the registry key, but not vice versa.

Maybe they'll get back to me in another 6 weeks with a new update. Wow, it's been 6 weeks!

Microsoft just responded to my Dec 16th email. I asked:

I know you have plenty of other issues to look at. But, please give me some sort of idea  when you guys might try and reproduce this issue at your end?

Or, maybe you have already attempted to reproduce the issue?

Either way, I'd love to get some sort of insight into how many more weeks before we get confirmation?

Their response, and I quote:

Hello Andy,
 
Please accept my sincere apology for delayed support on behalf of my team.
I deeply regret for the inconvenience caused; we are currently experiencing very High Case Volume.

The delay isn’t intentional, and we are known to provide timely assistance during normal business situation. We are taking right measures to overcome current situation by adding more trained resources and we should be able to provide you excellent support once again soon.

Please allow me some time to gte back to you with more information.