An application of my company becomes paths passed. Now we encountered errors, because we got paths like this: \\?\UNC\server\share\path\file
I was confused about this syntax, because I never saw it before. Also as far as I know each path starting with \\ is already a UNC path. So why should it masked to be an UNC path.
After some research in the Internet I found these articles:
The first article says:
Use a backslash as required as part of volume names, for example, the "C:" in "C:\path\file" or the "\\server\share" in "\\server\share\path\file" for Universal Naming Convention (UNC) names.
Which sounds like that "\\server\share\path\file" is already a valid UNC path. So there should be no need to use the other syntax to extend the path length.
But the second article says:
The "\\?\" prefix can also be used with paths constructed according to the universal naming convention (UNC). To specify such a path using UNC, use the "\\?\UNC\" prefix. For example, "\\?\UNC\server\share", where "server" is the name of the computer and "share" is the name of the shared folder. These prefixes are not used as part of the path itself. They indicate that the path should be passed to the system with minimal modification, which means that you cannot use forward slashes to represent path separators, or a period to represent the current directory, or double dots to represent the parent directory. Because you cannot use the "\\?\" prefix with a relative path, relative paths are always limited to a total of MAX_PATH characters.
So that strange syntax is indeed specified by Microsoft. But the syntax seems not to be supported by Windows. I can access any existing file using \\server\share\path\file but no file using \\?\UNC\server\share\path\file
Was this weird UNC syntax ever valid or has been disabled with newer Windows versions?
The \\?\UNC\server\share\path\file syntax is only valid for single file commands such as CreateFile, GetFileAttributesEx, ... and is required if you want to access server files which exceed the MAX_PATH limit, unless you have set the registry key from the second link in the question.
Unfortunately some commands, such as FindFirstFile, don't support this syntax. So if you want to list such a folder you need to remove this prefix.
My solution is to append this syntax for single file access commands and removing it for file browser commands. I do this before the corresponding API calls.
So the answer for this question is: Yes, this syntax is valid and sometimes required, but it is not supported in every WinAPI command.
External links referenced by this document: