Windows 11 Length of File Names in Windows 11 compared to Windows XP

ChatGPT said:

---

Quick question (so I can give the exact best fix)​

When Windows 11 rejects one, can you paste one full example path (or even just the last few folders + filename) and the exact error text Windows shows?
That will let me tell you immediately whether it’s:

• the 260-character path issue (most likely), or
• a 255-character single filename issue (rare), or
• something else (invalid characters, reserved names, etc.).

Click to expand...

My Windows 11 Hard Drive is NTFS as is my Windows XP Drive. The problem indicated by the Pop-up Window was the 260-character path issue.

I implemented your Fix 2 (Windows 11 Pro): enable “Win32 long paths”, but the 'File Explorer' programme still gave problems refusing to copy Files with long Directory Paths, and it also refused to copy Files it suspected of having Viruses. I then used your Fix 3: the ROBOCOPY Command which worked perfectly in copying all Windows XP Files irrespective of Size or suspicion of Viruses. I used the following Arguments: >robocopy "source directory" "destination directory" /e /r:1 /w:1 /copyall . However, I did have to Log on as "Administrator" because the Robocopy Command returned back with a permissions error when I was logged on under my personal User ID.

Hi TerryMz,
Great follow‑up — and you actually discovered the same solution many system administrators use when dealing with long paths and stubborn files.

Why File Explorer still failed even after enabling “Win32 long paths”​

Enabling Win32 long paths only removes the 260‑character limit for applications that support the modern Windows API. Unfortunately:

• Parts of File Explorer still use older APIs
• Some Windows components still enforce the 260‑character MAX_PATH limit

So even with the policy enabled, Explorer can still refuse long paths. This is a long‑standing Windows quirk.

Why ROBOCOPY worked​

robocopy is designed as a low‑level file replication tool, so it:

• Handles very long paths
• Ignores many Explorer limitations
• Can copy files even when metadata or permissions are unusual
• Does not block files just because Windows Defender is suspicious

Your command was very solid:
robocopy "source directory" "destination directory" /e /r:1 /w:1 /copyall
What your switches did:

• /E – copy all subfolders including empty ones
• /R:1 – retry once on failure
• /W:1 – wait 1 second between retries
• /COPYALL – copy all attributes, timestamps, ownership, and permissions

That last one is why you needed Administrator privileges.

Why Administrator was required​

/COPYALL includes:

• NTFS permissions (ACLs)
• owner information
• audit information

Standard user accounts normally cannot assign those attributes, so Windows blocks the operation unless you run elevated.
If you ever want to avoid that requirement, you can use:
robocopy "source" "destination" /e /r:1 /w:1 /copy:DAT
That copies:

• Data
• Attributes
• Timestamps

…but skips security ownership information.

About the “virus suspicion” blocks​

Explorer often refuses files because:

• Windows Defender flags them
• “Mark of the Web” metadata
• legacy executable formats from older systems

robocopy bypasses those UI checks because it operates directly at the file system level. It copies the file without trying to interpret it.
That’s why migration tools and backup systems typically use robocopy internally.

Bottom line​

Your migration approach ended up being the best possible method:

1. Enable long path support
2. Use robocopy for the actual copy
3. Run as Administrator when preserving full NTFS metadata

That is essentially enterprise‑grade file migration practice, even though you're just moving data from an XP drive.

One small optional improvement​

For large transfers, many admins also add:
/MT:8
This enables multi‑threaded copying, which can speed up transfers significantly on modern hardware.
Example:
robocopy "source" "destination" /e /r:1 /w:1 /copyall /mt:8

---

If you're interested, there is also a very old Windows design decision from the 1990s that still causes the 260‑character path limit today. It's a strange historical artifact from DOS and Windows NT that Microsoft never fully removed. I can explain it if you're curious — it's actually a pretty interesting bit of Windows history.

ChatGPT said:

---

If you're interested, there is also a very old Windows design decision from the 1990s that still causes the 260‑character path limit today. It's a strange historical artifact from DOS and Windows NT that Microsoft never fully removed. I can explain it if you're curious — it's actually a pretty interesting bit of Windows history.

Click to expand...

Please do explain this for the public record, and for other users in need. Thanks.

Hi TerryMz,
This is a surprisingly interesting piece of Windows history, and it explains why the 260‑character path limit still appears today even though modern Windows can technically handle much longer paths.

The origin: MS‑DOS design (1980s)​

Windows inherited many design decisions from MS‑DOS, which was created in the early 1980s when:

• computers had very little memory
• file systems were simple
• long directory structures were uncommon

In DOS, the maximum path length was defined as 260 characters. Internally it was stored in a buffer called MAX_PATH.
That buffer contained:

• 256 characters for the path
• plus extra characters for things like the drive letter (C:) and terminating characters.

So the Windows programming constant became:
MAX_PATH = 260
This limit was built directly into many early Windows programming interfaces.

Windows NT actually removed the limit (1993)​

When Microsoft created Windows NT (the architecture used by Windows 2000, XP, Vista, 7, 10, and 11), they designed a much more advanced file system layer.
Internally, NTFS can support paths up to roughly:
32,767 characters
So technically Windows has supported extremely long paths for over 30 years.
But there was a catch.

The compatibility problem​

Millions of Windows programs written since the early 1990s assumed that:
MAX_PATH = 260
Developers hard‑coded that assumption into software.
If Microsoft suddenly removed the limit completely, many older applications would:

• crash
• corrupt memory
• mis-handle file paths

So Microsoft kept the 260‑character restriction in the common Win32 APIs, even though the underlying NT kernel could handle much longer paths.

The “long path” workaround​

NT actually supports long paths using a special syntax:
\\?\C:\VeryLongPath\...
The \\?\ prefix tells Windows:

“Bypass the old MAX_PATH Win32 checks and pass the path directly to the NT kernel.”

Click to expand...

System tools like robocopy, backup software, and some developer tools use this internally.
That’s why robocopy worked for you even when File Explorer failed.

What Microsoft did in modern Windows​

Starting with Windows 10 (2016) Microsoft added the policy you enabled:
Enable Win32 long paths
This allows modern applications to bypass the 260‑character restriction.
However:

• many older programs still assume MAX_PATH
• parts of File Explorer still use legacy APIs
• some installers and utilities still enforce the old limit

So the limit still appears in certain situations.

Why the issue shows up during file transfers​

When copying files between drives, the problem is usually not the filename, but the entire path, for example:
C:\Users\YourName\Documents\Old Computer Backup\Projects\2004\Archived Reports\Final Versions\Very Long File Name.doc
If the total path exceeds about 260 characters, Explorer may refuse the copy operation.
Tools like robocopy succeed because they use lower‑level NT APIs that support long paths.

Why Windows XP sometimes seemed better​

Windows XP actually had the same underlying limit, but users often didn’t notice it because:

• XP profiles were shorter (e.g., C:\Documents and Settings\)
• folder structures were simpler
• cloud syncing folders didn’t exist
• applications used shorter naming conventions

Modern Windows paths like:
C:\Users\username\OneDrive\Documents\Projects\...
can grow very long very quickly.

The irony​

The funny part is that the real technical limit today is about:
32,767 characters
…but because of decades of software compatibility, many parts of Windows still behave as if the limit were 260.
That small design decision from the DOS era (over 40 years ago) is still affecting Windows users today.

---

If you're interested, there’s another similar historical artifact in Windows that dates all the way back to 1960s teletypes, and it’s the reason Windows still uses the mysterious characters:
CR + LF
at the end of every line in text files. It’s another case where a very old design decision still affects modern computers.