Using \\?\ to exceed MAX_PATH

26 Mar 2017

In my last article I suggested that you probably wanted to escape paths for reasons other than MAX_PATH. Unfortunately the prefix suppresses relative path translation, which is frequently desired. GetFullPathName might work up to a point, but it has a fairly fatal flaw:

After much consideration about how to solve this in sdir I ended up realizing that the only solution was to reimplement GetFullPathName in a way that preserves the escaped behavior throughout the entire process, but does perform relative path translation. This addresses the issue in the last article, because having done so, all \\?\ is doing is allowing files with trailing spaces, periods, and device names - which is probably what you wanted anyway. Users are then able to enumerate relatively named subdirectories from a current directory that's approaching MAX_PATH and still have semantically correct behavior.

Obviously I can't promise that it's perfect, but it is the product of a large number of unit tests exercised against GetFullPathName to mimic its behavior. Some of that behavior is asinine - things like "\\Server\Share\..\foo" translating to "\\Server\Share\foo" may make sense to somebody somewhere, but it's not natural for a software parser.

If you're interested in following a similar approach or leveraging this support, it's in the Sdir source, which is licensed under the MIT license - see SdirGetFullPathName and SdirGetFullPathNameReturnAllocation.

But isn't MAX_PATH going away?

Maybe it will. But if it does, the issues in the last article still apply. You can either write software that depends on a new version of Windows but can't process names with trailing spaces, periods, or happen to use DOS-era device names; or you can take this opportunity to ensure your software is cross platform clean, and works on all modern versions of Windows. It's up to you.