Remove MAX_PATH Limitations

 

As technology advances, applications increase their complexity. As a result, installers deploy more and more files and folders to the install directories.  Software developers should not rely on the Window’s MAX_PATH constant when developing their applications. Many Windows APIs don’t support file paths that are longer than MAX_PATH in length directly. However, they do support these files under some rules. I recommend you to follow this guideline when working with file APIs.

1 : Never use MAX_PATH constant in the code. Most of us tend to allocate buffers with a magic number. However, this is not a good practice as it may introduce security threats and reduce the robustness of program. Instead, use a vector object as a buffer. You will have the power of changing its size based on your file path length.

image

2 : Prepend [\\?\](file://\\?\) characters to the file paths that are longer than MAX_PATH. Most Windows APIs support file paths that are longer than MAX_PATH in length IFF file path contains [\\?\](file://\\?\) prefix. However, do not prepend this prefix to the file paths that are less than MAX_PATH in length as prepending this prefix causes APIs to skip some validations that are valuable for the program.

image

3: Of course, do not use Windows APIs that do not support file paths that are longer than MAX_PATH in length. Some APIs fail even if you prepend the [\\?\](file://\\?\) prefix to the file path. SHFileOperation is one example to these APIs.

4: Wrap the Windows APIs to your own functions so that you will have one entry to control if you need to make any change to the API. 

image

5: Write unit test! To ensure that your code works fine for any file paths with any lengths, write your unit test and validate your code.