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
\\?\C:\Verrrrrrrrrrrry 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 <...>.
\\?\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.