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?
Best Answer
.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:
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:
Warning: You might need to call the Windows APIs directly, since I think the .NET Framework might not support this kind of path syntax.