Maximum Path Length
In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is:
D:\<some 256 character path string><NUL>
Where <NUL> represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.) File I/O functions in the Windows API convert / to \ as part of converting the name to an NT-style name, except when using the \\?\ prefix as detailed in the following sections.
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>. (The characters < > are used here for visual clarity and cannot be part of a valid path string.) The maximum path of 32,767 characters is approximate, because the \\?\ prefix may be expanded to a longer string by the system at run time, and this expansion applies to the total length.
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 machine 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. Also, you cannot use the \\?\ prefix with a relative path, therefore relative paths are limited to MAX_PATH characters as previously stated for paths not using the \\?\ prefix.
There is no need to perform any UNICODE normalization on path and file name strings for use by the Win32 file I/O API functions because the filesystem treats path and file names as an opaque sequence of WCHARs. Any normalization your application requires should be performed with this in mind, external to any calls to related Win32 file I/O API functions. When using an API to create a directory, the specified path cannot be so long that you cannot append an 8.3 file name (that is, the directory name cannot exceed MAX_PATH minus 12). The shell and the file system have different requirements. It is possible to create a path with the Windows API that the shell user interface might not be able to handle.
For functions that manipulate files, the file names can be relative to the current directory. A file name is relative to the current directory if it does not begin with one of the following:
If the file name begins with a disk designator with a backslash, it is a fully qualified path (for example, C:\tmp). If a file name begins with only a disk designator but not the backslash after the colon, it is interpreted as a relative path to the current directory on the drive with the specified letter. Examples of this format are as follows:
A path is also said to be relative if it contains double-dots; that is, two periods together in one component of the path. This special specifier is used to denote the directory above the current directory, otherwise known as the parent directory. Examples of this format are as follows:
Relative paths can combine both example types, for example C:..\tmp.txt. This is useful because, although the system keeps track of the current drive along with the current directory of that drive, it also keeps track of the current directories of all of the different drive letters if your system has more than one. As stated previously, you cannot use the \\?\ prefix with a relative path because it is considered a form of UNC naming.
Short and Long File Names and Paths
Typically, Windows stores the long file names on disk as special directory entries, which can be disabled system wide for performance reasons depending on the particular file system. When you create a long file name, Windows may also create a short MS-DOS (8.3) form of the name, called the 8.3 alias, and store it on disk. Starting with Windows 7 and Windows Server 2008 R2, this can also be disabled for a specified volume. On many file systems, a short file name contains a tilde (~) character within each component when it is too long to comply with 8.3 naming rules, as previously discussed. Take note that not all file systems follow this convention, and systems can be configured to disable 8.3 alias generation even if they normally support it. Therefore, do not make the assumption that the 8.3 alias already exists. To request 8.3 file names, long file names, or the full path of a file from the system, consider the following options:
On newer file systems, such as NTFS, ex-FAT, UDFS, and FAT32, Windows stores the long file names on disk in Unicode, which means that the original long file name is always preserved. This is true even if a long file name contains extended characters and regardless of the code page that is active during a disk read or write operation. The case of the file name is preserved, even when the file system is not case-sensitive. Files using long file names can be copied between NTFS file system partitions and Windows FAT file system partitions without losing any file name information. This may not be true for MS-DOS FAT and some types of CDFS (CD-ROM) file systems, depending on the actual file name. In this case, the short file name is substituted if possible.