GetFullPathNameW and long Windows file paths
GetFullPathNameA
is limited toMAX_PATH
characters, because it converts the ANSI name to aUNICODE
name beforehand using a hardcodedMAX_PATH
-sized (in chars)UNICODE
buffer. If the conversion doesn't fail due to the length restrictions, thenGetFullPathNameW
(or directGetFullPathName_U[Ex]
) is called and the resultingUNICODE
name is converted to ANSI.GetFullPathNameW
is a very thin shell overGetFullPathName_U
. It is limited toMAXSHORT (0x7fff)
length in WCHARs, independent of the\\?\
file prefix. Even without\\?\
, it will be work for long (>MAX_PATH
) relative names. However, if thelpFileName
parameter does not begin with the\\?\
prefix, the result name in thelpBuffer
parameter will not begin with\\?\
either.if you will be use
lpBuffer
with functions likeCreateFileW
- this function internally convertWin32Name
toNtName
. and result will be depended from nape type (RTL_PATH_TYPE
). if the name does not begin with\\?\
prefix, the conversion fails becauseRtlDosPathNameToRelativeNtPathName_U[_WithStatus]
fails (because if the path not begin with\\?\
it will be internally callGetFullPathName_U
(same function called byGetFullPathNameW
) withnBufferLength
hardcoded to MAX_PATH (exactly2*MAX_PATH
in bytes – NTDLL functions use buffer size in bytes, not inWCHAR
s). If name begin with\\?\
prefix, another case inRtlDosPathNameToRelativeNtPathName_U[_WithStatus]
is executed –RtlpWin32NtNameToNtPathName
, which replaces\\?\
with\??\
and has noMAX_PATH
limitation
So the solution may look like this:
if(ULONG len = GetFullPathNameW(FileName, 0, 0, 0))
{
PWSTR buf = (PWSTR)_alloca((4 + len) * sizeof(WCHAR));
buf[0] = L'\\', buf[1] = L'\\', buf[2] = L'?', buf[3] = L'\\';
if (len - 1 == GetFullPathName(FileName, len, buf + 4, &c))
{
CreateFile(buf, ...);
}
}
So we need to specify a path with the \\?\
prefix attached, but not before GetFullPathName - after!
For more info, read this - The Definitive Guide on Win32 to NT Path Conversion