Windows File Name Too Long: Enable Long Paths, Why File Explorer Still Fails

A hands-on test published by MakeUseOf's Afam Onyimadu shows the problem clearly. Microsoft's own documentation explains why. Below is what the setting does, how to turn it on, how to tell whether it worked, and what to do when it doesn't.

The test: one registry change, two different results​

Onyimadu ran the test on a PC he reports as Windows 11 25H2, build 26200.9457. On that machine, LongPathsEnabled was set to 0 by default.

1. He made an empty folder on the Desktop and kept nesting long-named folders inside it until, by his count, the full path was 239 characters.
2. He then tried to create one more folder, Folder_7_123456789012, a 21-character name that he says brought the path to 261 characters.
3. File Explorer refused with this dialog: "The file name(s) would be too long for the destination folder."
4. Before changing anything, he tried the same path with New-Item in Windows PowerShell 5.1. That failed too.
5. He set LongPathsEnabled to 1, restarted the PC, checked that the value had stuck, and ran both tests again.

Same PC, same path, one registry value changed. PowerShell started working and Explorer behaved exactly as before. These results come from one machine. The build number, the path lengths and the Explorer behavior are the author's report, not independent measurements.

Section summary: the long-path switch works, but only for programs that are built to use it.

Why the setting helps PowerShell but not Explorer​

Microsoft's "Maximum Path Length Limitation" page covers this directly. Starting in Windows 10, version 1607, MAX_PATH limitations have been removed from many common Win32 file and directory functions. However, your app must opt-in to the new behavior.

Two separate conditions have to be met: a registry value must be set, and the application manifest must include the longPathAware element. Microsoft also states that enabling this registry setting will only affect applications that have been modified to take advantage of the new feature.

In other words, the registry value gives permission and each app's manifest accepts it. If an app hasn't declared itself long-path aware, the setting does nothing for it.

On Explorer, Onyimadu says he can only assume its manifest lacks the longPathAware entry. That is a reasonable guess, but it is not confirmed. Other sources point the same way:

• Microsoft's documentation says the shell and the file system have different requirements. It is possible to create a path with the Windows API that the shell user interface is not able to interpret properly.
• OpenText/Micro Focus, in its Open Enterprise Server client admin guide, says Microsoft's File Explorer, even on Windows 11, does not support paths beyond MAX_PATH limits without issue.

So this isn't one odd PC. It matches how Windows is designed to work.

What "260 characters" actually counts​

The error says "file name," but the limit applies to the whole path. Microsoft says that in the Windows API, the maximum length for a path is MAX_PATH, which is defined as 260 characters. That total includes the drive letter, colon, every backslash, every parent folder name and an invisible terminating null character.

A Desktop folder already uses a lot of that budget, because Desktop sits under your user profile. That is why a modest 21-character folder name pushed Onyimadu's path over the limit.

Microsoft also describes a stricter rule for creating folders: the specified path cannot be so long that you cannot append an 8.3 file name (that is, the directory name cannot exceed MAX_PATH minus 12). In practice, a folder path can fail even before it reaches 260 characters.

Section summary: the error is about the full path. Every parent folder counts.

How to enable Win32 long paths (Windows 10 1607 and later, Windows 11)​

You need administrator rights for any of these methods. Use whichever one suits you.

Option 1: PowerShell (elevated)​

Microsoft documents this command. Run it from an elevated terminal:

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

Option 2: Command Prompt (elevated)​

WinOSHub gives the reg.exe equivalent: reg add "HKLM\SYSTEM\CurrentControlSet\Control\FileSystem" /v LongPathsEnabled /t REG_DWORD /d 1 /f

Option 3: Group Policy (Pro, Enterprise, Education)​

1. Open gpedit.msc.
2. Go to Computer Configuration > Administrative Templates > System > Filesystem.
3. Enable Enable Win32 long paths.
4. Restart.

Option 4: Intune, for managed fleets​

Microsoft notes that the same policy can also be controlled via Group Policy or deployed with Microsoft Intune through the Policy Configuration Service Provider (CSP). Remember that deploying the policy does not prove your apps support long paths. App opt-in is still a separate requirement.

Restart​

Don't skip the reboot. Microsoft says the value is cached by the system (per process) after the first call to an affected Win32 file or directory function... The registry value will not be reloaded during the lifetime of the process. Its wording is that a reboot might be required because some processes may have started before the key was set. Strictly, a newly launched process should pick up the change. A full restart is simply the easiest way to make sure nothing is still running with the old value, which is what Onyimadu did.

Checking whether it worked​

• Check the value: in a terminal, run reg query "HKLM\SYSTEM\CurrentControlSet\Control\FileSystem" /v LongPathsEnabled. Success looks like 0x1.
• Check the app: WinOSHub suggests looking for longPathAware in the app's manifest. It notes the manifest is sometimes a separate XML file stored in the application directory, but more often it is embedded within the executable (.EXE) file.
• Test it yourself: repeat whatever failed before. If Explorer still shows the same dialog, as it did in the MakeUseOf test, the setting is fine. Explorer just isn't using it.

Common sticking points and fixes​

Explorer still says the name is too long. This is expected. Shorten the path: rename parent folders to something shorter, or move the folder closer to the root of the drive (for example, out of Desktop and into a short top-level folder). Onyimadu calls this the more dependable fix for Explorer. Our own view is that it's the safest general fix, since it doesn't depend on any app supporting long paths.

Git clones fail with "Filename too long." Git has its own switch, separate from Windows. Developer Andrew Lock notes that Git has its own long path support that can be enabled independently by setting core.longpaths=true, by running git config --global core.longpaths true. Microsoft's documentation uses cloning a repo with long file names into an already long folder as its example of hitting this limit.

Build tools fail with errors that don't look path-related. A CMake bug report describes paths over the limit failing even when the system is configured to support longer paths. Some file operations pass with such a long path, while others fail with seemingly unrelated messages. If a build error makes no sense, check whether a long absolute path is involved.

Relative paths still fail. Microsoft notes that because the \\?\ extended-length prefix can't be used with relative paths, relative paths are always limited to a total of MAX_PATH characters. Use absolute paths when testing.

Python and R. The R Project blog notes that Python already does that and the Python installer offers to enable long paths in the system. If you have ever clicked through that installer prompt, the setting may already be on.

How long can paths get? NinjaOne says that with the setting on, the file path length limit increases to 32,767 characters, but some applications might use the default limits. Microsoft calls that figure approximate. Each folder or file name is still limited by the file system, usually to 255 characters.

Why is it still off by default?​

Onyimadu suspects the opt-in design protects older software, and he points out that Microsoft hasn't confirmed this. Andrew Lock is more direct: Microsoft are dedicated to backwards compatibility, almost to a fault.

The OpenText documentation explains the technical risk. The longPathAware flag tells Windows that it would be safe to return a path longer than MAX_PATH to this application, because the application has been suitably designed or re-designed to handle such paths without crashing or overwriting memory. An app built with a fixed 260-character buffer that suddenly receives a 400-character path could crash or corrupt memory. That's a fair reason for caution, even if the dialog could at least mention that a setting exists.

For administrators, the practical advice is to test before rolling it out widely. Daniel Cosenza's compatibility guide makes the same point: test the software estate and deployment path before broad rollout.

Bottom line​

Turn on LongPathsEnabled if PowerShell, Git, Python or other long-path-aware tools keep hitting the 260-character limit. Restart, then retest. In this test, the setting made no difference to File Explorer, so for Explorer the reliable fix is still a shorter path.

Onyimadu's main takeaway holds up. "File name too long" isn't really about the file name. It means the program you're using hasn't opted in to long paths.