C ++ WinAPI: handling long paths / file names

Question

I am looking at handling longer file paths in my Windows application.

Currently I have a text box (edit box) in which the user can enter the absolute path to the file. Then I read this typed file path using GetWindowText into a line declared like this: TCHAR FilePath[MAX_PATH];

Obviously, here I rely on the constant MAX_PATH , which limits me to 260 characters. Therefore, to handle longer file and path names, I can simply expand my TCHAR array as follows: TCHAR FilePath[32767]; .

Or is there a better way? Can I use a variable length array? ( TCHAR FilePath[]; is this even possible in C ++? - sorry, I'm pretty new to this).

Thank you for the advanced!

---

Here's the whole piece of code that I mentioned above:

 TCHAR FilePath[MAX_PATH]; ZeroMemory(&FilePath, sizeof(FilePath)); GetWindowText(hWndFilePath, FilePath, MAX_PATH); 

Answer 1

There are a number of limitations to file paths in Windows. By default, paths cannot be longer than 260 characters, which is what the MAX_PATH constant is MAX_PATH .

However, you can access longer paths — with certain restrictions — by prefixing the path with "\\? \". However, the limitations of using the prefix "\\? \" Usually outweigh the advantage:

• There are several Win32 APIs that do not support support paths with this prefix (for example, LoadLibrary will always fail on a path longer than 260 characters)
• Winical Canonicalization rules do not take effect when using the prefix "\\? \". For example, by default, "/" in paths is converted to "\", ".". and ".." are converted to links to the current and parent directories respectively, etc .: none of this happens when you use the prefix "\\? \".
• Just because you can change your program to support longer paths, other programs may not open the files you created. This will be the case if these other programs also do not use the prefix "\\? \".

Honestly, point number 2 is a real killer: you discover all kinds of problems when using the "\\? \" Prefix, and you basically need to re-implement the Win32 canonicalization rules yourself if you go this route.

So my recommendation is to just stick to the 260 limit. At least until there is platform support for longer paths.

Answer 2

It depends on what program you are writing. My own strategy, as a rule, was to limit the creation of the path to MAX_PATH in length, but to be able to read existing data from longer paths (using the prefix "\? \" Dean mentions in his answer). There are exceptions to this, although, for example, the backup program must take long paths and must accurately reproduce what it was specified as input.

While Dean is certainly right that Windows does not canonize longer paths for you, I have not found this to be of great concern as a general rule. This, as a rule, does not mean that you create your own code for canonicalizing the path: this usually means that the user enters the path in such a way that they simply do not generate such things in the first place.

Answer 3

No, because if you get a longer path, Windows will not be able to accept it. Thus, although technically you could have more characters than in your buffer, you could never use the result of a file.