260+ character MAX_PATH limitations in filenames

Accessing files with a full path\filename of greater than the traditional MAX_PATH constant of 260 characters can still be challenging in today's Operating Systems. This article provides some insight into the problem, and methods to identify and workaround the issue.

Identifying the problem

The problem occurs through common applications, explorer, Office apps, command prompt, and sometimes returns meaningful errors (the full path 'x' is too long – md/mkdir) but often returns nothing (explorer) or an obscure error.

One method I use to identify these problems – particularly because they usually occur when trying to copy the data – is robocopy.


The verbose logs from a robocopy command will identify this particular error with a general syntax error, but it's easy enough to tell with the path referenced if it's a 260+ problem. The text logged by robocopy (version XP010 in this case) is:
"ERROR 123 (0x0000007B)"

Testing

Testing was completed, showing that:

• The server name and share name definitely do count as part of
  the total 260 character path limitation when using UNC references, eg file://server/share
• However, when using a mapped drive, the server name and share
  name are irrelevant; it is the constructed path with the drive letter that counts, eg: f:\
• Despite various Microsoft articles, using the \\?\ syntax to
  disable path parsing does not force use of the Unicode equivalent function (which didn't really make sense anyway).

Workaround

Three successful methods to work around this issue have been tested, detailed below.

Method 1 - Use a utility that can bypass the 260 character limitations by using the Unicode version of the CopyFile() function (CopyFileW).

I used a utility called FastCopy, which supports paths longer than 260 characters, presumably by using the Unicode version of the relevant functions.

Method 2 - Use the 8.3 short filenames generated by the filesystem to reduce the path.

This didn't occur to me until I was nearly finished with this exercise, and while it's easier to access individual files in this way, batching this to copy disparate files is not so easy.

Method 3 - Create a share deeper in the directory path, and access the file through the share, either UNC or mapped drive.

This isn't very practical in most situations, but if it's possible to create new shares, this is probably the easiest method.

Other testing completed:

• Copying through explorer also has the same results.
• Tried with the "\\?\f:\" syntax, which made the problem worse (because of the extra few characters), even though this is supposed to bypass 260 character limitations using the Unicode function.
• Accessing the file locally on the 2003 SP2 R2 server, or
  remotely via XPSP2 has the same result (with a mapped drive)
  

References

CopyFile function

http://msdn2.microsoft.com/en-us/library/aa363851(VS.85).aspx

Naming a Volume
http://msdn2.microsoft.com/en-us/library/aa365248(VS.85).aspx

Making Room for Long Filenames
http://msdn2.microsoft.com/en-us/library/ms810456.aspx

Naming a File
http://msdn2.microsoft.com/en-us/library/aa365247.aspx


Wayne's World of IT (WWoIT), Copyright 2008 Wayne Martin.