Question

I’m working on an application which walks through every file in some directories and does some actions with those files. Among others, I must retrieve the file size and the date when this file was modified.

Some file full names (directory + file name) being too long, I couldn’t use .NET Framework FileInfo, which is limited to MAX_PATH (260 characters). Many web sources advised to use native Win32 functions through P/Invoke to access the files whose names are too long.

Currently, the exactly same problem seems to arise with Win32 functions. For example, GetFileAttributesEx (kernel32.dll) fails with Win32 error 3 ERROR_PATH_NOT_FOUND for the path of 270 bytes.

The very same file can successfully be opened from Notepad2 and successfully displayed with Windows Explorer (but Visual Studio 2010 for example fails to open it because of the 259 characters limit¹).

What can I do to be able to access a file when the file path is 270 characters long?

Notes:

• Removing or ignoring files with the file path length longer than 259 characters is not a solution.

• I’m looking for Unicode-compatible solutions only.

• The application will run under Windows 2008/Vista or later with .NET Framework 4 installed.

---

^{¹ Surprisingly, Microsoft Word 2007 fails, complaining that “the floppy disk is too small” on a computer which don’t have any floppy drive, or that “RAM memory is low” when there is 4 GB of RAM left, or finally that “antivirus software […] needs to be updated”. Will they stop one day displaying such stupidly meaningless errors at least in such key products as Microsoft Office?}

Answer 1

.NET 4.6.2 Solution

Use the \\?\C:\Verrrrrrrrrrrry long path syntax as described here.

.NET Core Solution

It just works because the framework adds the long path syntax for you.

Pre .NET 4.6.2 Solution

Also use the long path syntax and the Unicode version of the Win32 API function with P/Invoke.
From Naming Files, Paths, and Namespaces:

The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the \\?\ prefix. For example, \\?\D:\very long path.

Reading this Microsoft Support page might also be interesting.

A very extensive explanation in Long Paths in .NET by Kim Hamilton at the BCL Team blog lists a few hitches in handling these paths which he claims are the reason this syntax is still not supported in .NET directly:

There are several reasons we were reluctant to add long paths in the past, and why we’re still careful about it <…>.

<…> the \\?\ prefix not only enables long paths; it causes the path to be passed to the file system with minimal modification by the Windows APIs. A consequence is that \\?\ turns off file name normalization performed by Windows APIs, including removing trailing spaces, expanding ‘.’ and ‘..’, converting relative paths into full paths, and so on.<…>

<…> Long paths with the \\?\ prefix can be used in most of the file-related Windows APIs, but not all Windows APIs. For example, LoadLibrary<…> fails if the file name is longer than MAX_PATH. <…> There are similar examples throughout the Windows APIs; some workarounds exist, but they are on a case-by-case basis.

Another factor <…> is compatibility with other Windows-based applications and the Windows shell itself <…>

Because this problem is becoming increasingly common <…> there are efforts throughout Microsoft to address it. In fact, as a timely Vista plug, you’ll notice a couple of changes that reduce the chance of hitting the MAX_PATH limit: many of the special folder names have shortened and, more interestingly, the shell is using an auto-path shrinking feature <…> to attempt to squeeze them into 260 characters.

---

Warning: You might need to call the Windows APIs directly, since I think the .NET Framework might not support this kind of path syntax.