Folder 14 of 30: When Windows' 260-Character Limit Quietly Kills a Backup

At 11:40 on a Sunday night, my backup job stopped at 'Folder 14 of 30.' No crash. No dialog worth reading. Just a progress bar that had been stuck long enough for me to start pricing replacement drives.

The culprit wasn't the drive. It was a folder name. Specifically, a chain of folders deep enough that the full path crossed 260 characters, which is where a surprising amount of Windows software still gives up. In 2026. On a machine with 32 GB of RAM and a PCIe 4.0 SSD.

If you've seen a copy, sync, or backup stall with an error like 'The file name you specified is not valid or too long'—or worse, no file name at all—this is for you. Here's how the limit works, how to prove it's the problem, and what actually fixes it.

Why 260 Characters Still Matter in 2026

The number comes from MAX_PATH, a constant baked into the Windows API back in the Windows 95 era. It's 260 characters including the terminating null character, which leaves 259 usable. That was plenty when file names were eight characters and a three-letter extension. It is not plenty when a backup tool creates paths like D:\Backups\2026\Laptop\Users\Chris\AppData\Local\Packages\SomeVendor.SomeApp_8wekyb3d8bbwe\LocalState\...

Microsoft added long-path support in Windows 10 version 1607, but it's opt-in at two levels: the operating system setting and the application's manifest. That second part is where things fall apart. A program built with old assumptions can still hit the wall even after you flip the switch. And plenty of backup utilities, installers, and sync clients are built on those old assumptions.

Before You Touch the Registry, Confirm the Diagnosis

Don't start editing system settings on a hunch. First, find the path that's failing. Check the backup log—most tools write the last file they touched, even if the error message is useless. If the log is empty, recreate the failure by copying the folder in File Explorer to a short destination like C:\T\.

If the copy fails at roughly the same spot, measure the path. In PowerShell 7 (which handles long paths better than Windows PowerShell 5.1), run:

Get-ChildItem -LiteralPath 'D:\Backups' -Recurse -Force -ErrorAction SilentlyContinue | Where-Object { $_.FullName.Length -gt 240 } | Select-Object FullName, @{n='Length';e={$_.FullName.Length}}

If you see paths in the 240–260 range, you've found your suspect. A quicker tell: the error code 0x800700DF, which Explorer translates to a file-size message that has nothing to do with file size. Microsoft's own documentation calls this out, but the dialog still confuses people.

The Registry Switch That Helps—Sometimes

This is the setting most guides point to, and it's worth doing:

1. Open Registry Editor as administrator.
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem.
3. Find LongPathsEnabled. If it's missing, create a DWORD (32-bit) value with that name.
4. Set it to 1.
5. Reboot.

Or from an elevated PowerShell window:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' -Name 'LongPathsEnabled' -Value 1 -Type DWord

That tells Windows to allow paths beyond 260 characters for applications that declare support. It does not rewrite the rules for applications that don't. This is the part people miss. After the reboot, Explorer handled my over-nested test tree. My backup tool still skipped two files. More on that below.

The Group Policy Route

If you're on Windows Pro or Enterprise, or you manage a small office, the same setting lives in Group Policy:

Computer Configuration > Administrative Templates > System > Filesystem > Enable Win32 long paths

Set it to Enabled, then run gpupdate /force from an elevated command prompt. It writes the same registry value, so don't do both and assume you've doubled the effect. You haven't.

What Still Ignores the Fix

Long-path support is not a blanket pardon. Applications need to be compiled with a manifest that declares longPathAware. Older backup suites, some file-sync clients, and a surprising number of installers don't do that. During testing, I ran into four flavors of failure:

• Explorer copy: worked after the registry change and reboot, but only on the current Windows 11 build. Older builds and some dialogs still choke.
• Robocopy: handled the deep tree before and after the change. It has its own long-path handling and doesn't care about MAX_PATH in the same way.
• 7-Zip: would not archive the deepest folder until I prefixed the source path with \\?\. The command-line version handled it more gracefully than the GUI.
• One backup utility: skipped the two deepest files and logged a generic read error. The vendor's documentation says long paths are supported 'where the operating system allows it,' which is a fancy way of saying check your manifest.

Network paths add another layer. SMB shares and mapped drives can impose their own limits, and the \\?\ prefix doesn't work the same way with UNC paths unless you use \\?\UNC\server\share.

My Over-Nested Test Tree

I built a deliberately silly folder structure: 18 nested folders, each named with a 32-character string, plus a handful of small files at the bottom. Total path length at the deepest file: 612 characters. Then I copied it four ways.

Explorer failed at 258 characters before the registry change. After the change and a reboot, it completed. Robocopy completed both times. FreeFileSync completed after the change, but an older build I keep for testing skipped the deepest file. 7-Zip's GUI refused to add the folder until I used the \\?\ prefix from the command line.

The lesson: the registry switch is necessary but not sufficient. The application has to cooperate.

A Practical Playbook for the Rest of Us

If you're staring at a half-finished backup, here's the order I'd work in:

1. Shorten the root. Move the backup destination closer to the drive letter. D:\B\ beats D:\Backups\2026\Full System\Laptop\.
2. Flatten vendor folders. If a program creates absurdly deep cache paths, exclude those folders from the backup. You probably don't need them.
3. Enable long paths. Registry or Group Policy, then reboot.
4. Use robocopy for bulk copies. It's free, built in, and handles deep trees better than Explorer. A simple robocopy 'D:\Source' 'E:\Dest' /E /COPY:DAT /R:1 /W:1 will do more than most people expect.
5. Check your backup tool's docs. If it doesn't mention long paths or Win32 long path support, assume it will fail on deep trees and test before you trust it.
6. Use \\?\ sparingly. It works for absolute local paths and \\?\UNC\ for network paths, but not every app accepts it.

The 260-character wall is old, but it's not haunted. It's a default that no one bothered to change for decades, and it still trips up software that should know better. Once you know what to look for, the fix is usually a registry value, a reboot, and a backup tool that was actually built for 2026. And if your backup stops at Folder 14 of 30, check the path before you blame the drive.