Tired of hitting the dreaded 260-character path limit in Windows? Learn three practical, battle-tested solutions to bypass the `MAX_PATH` error, from a quick code fix to a permanent system-wide change.

So You Hit the Windows Path Limit Again… Let’s Fix That for Good.

I still remember the night it happened. 2 AM, a critical production deployment, and everything was failing. The build agent on `prod-build-ci-02` was throwing cryptic “File Not Found” errors, but I could see the files right there on the disk. After an hour of frantic debugging, we found the culprit: a deeply nested `node_modules` directory created by a front-end build process. The path was something like `D:\builds\agent-1\work\a1b2c3d4\src\WebApp\ClientApp\node_modules\@some-scoped-package\some-other-package\dist\js\…` and it had sailed right past the 260-character limit. The deployment script, running on an older version of PowerShell, just couldn’t see it. That night, I learned a lesson that every Windows-based engineer learns the hard way: the `MAX_PATH` limit is not a suggestion; it’s a ghost from the past that’s here to haunt you.

Recently, I saw a developer on Reddit wrestling with this exact problem in their C# code. It’s a rite of passage, but it doesn’t have to be a blocker. Let’s break down why this happens and how we, as engineers in the trenches, can fix it.

First, Why Does This Even Exist?

The root cause is a legacy constant from the dawn of Windows named MAX_PATH, which was set to 260 characters. This was plenty back in the MS-DOS days, but in our world of complex project structures and package managers, it’s comically small. While the underlying Windows NT filesystem (NTFS) can handle paths up to ~32,767 characters, many of the older Win32 file APIs—which a surprising number of applications and even parts of the OS still use—are hardcoded to respect the old `MAX_PATH` limit. This mismatch is the source of all our pain.

The Solutions: From Band-Aid to Surgery

Depending on your situation, control over the environment, and how quickly you need a fix, you have a few options. I’ve used all three in different scenarios.

1. The Quick Fix: The `\\?\` Prefix

This is the most direct, “I need to fix this one piece of code right now” solution. You can tell the Windows API directly that you want to use a long path by prefixing it with \\?\. This bypasses the old `MAX_PATH` check and sends the path straight to the filesystem.

If you’re writing a script or application, this is your go-to tactical fix. Let’s take the Redditor’s C# example:

// The Original Problem Code
string[] filePaths = Directory.GetFiles(myVeryLongPath, "*", SearchOption.AllDirectories);

// The Quick Fix
string longPath = @"\\?\" + myVeryLongPath;
string[] filePaths = Directory.GetFiles(longPath, "*", SearchOption.AllDirectories);

It’s that simple. The same principle applies in PowerShell, though you might need to use the `-LiteralPath` parameter with cmdlets to ensure the prefix is interpreted correctly.

# This might fail
# Get-ChildItem -Path "C:\very\long\path..."

# This will work
Get-ChildItem -LiteralPath "\\?\C:\very\long\path..."

Pro Tip: This fix is surgical. It only works for the specific code you apply it to. It won’t fix Windows Explorer or other tools that aren’t “long path aware”. Also, note that this prefix works for absolute paths only.

2. The Permanent Fix: Enable Win32 Long Paths System-Wide

Since Windows 10 Anniversary Update (version 1607), you can make a system-wide change to tell the OS to be more forgiving. This is my preferred solution for any build server, developer machine, or file server I manage.

You can enable this via the Registry or Group Policy.

Using Registry Editor (regedit.exe):

1. Navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
2. Find the DWORD value named LongPathsEnabled. If it doesn’t exist, create it.
3. Set its value to 1.
4. A reboot is often required for the change to take full effect across all processes.

You can also do this with a single PowerShell command (as an Administrator):

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1 -PropertyType DWord -Force

Warning: This is not a silver bullet! This only works for applications that have been manifested to support it. Most modern, 64-bit applications (like .NET Core, recent versions of PowerShell) will respect this setting. However, older 32-bit applications or tools that haven’t been updated may still fail.

3. The ‘Nuclear’ Option: Use a Better Tool

Sometimes you don’t have time to debug code or change registry settings. You just need to delete or move a folder that File Explorer can’t touch. This is where you bring out the heavy machinery.

Robocopy: The battle-hardened “Robust File Copy” utility built into Windows doesn’t care about `MAX_PATH`. It’s my go-to for deleting “undeletable” `node_modules` folders.

# To delete a problematic folder:
# 1. Create an empty directory
mkdir C:\temp\empty

# 2. Use robocopy to "mirror" the empty directory onto the problem one, purging it
robocopy C:\temp\empty "D:\builds\agent-1\work\a1b2c3d4\..." /purge

# 3. Clean up
rmdir C:\temp\empty
rmdir "D:\builds\agent-1\work\a1b2c3d4\..."

Windows Subsystem for Linux (WSL): The Linux kernel and its tools don’t use the Win32 file APIs. If you have WSL installed, you can often manipulate these long paths without any issue.

# From a WSL terminal (e.g., Ubuntu)
# Windows drives are mounted under /mnt/
cd /mnt/d/builds/agent-1/work/a1b2c3d4/
rm -rf the-problem-folder/

Which Solution Should You Choose?

Here’s how I decide:

Ultimately, the `MAX_PATH` issue is a legacy problem we just have to live with. But by understanding why it happens and keeping these tools in your back pocket, you can turn a late-night production disaster into a five-minute fix. For all my new servers, enabling long paths via the registry is one of the first things I do. It saves a world of pain down the line.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions