C++ WinAPI: handling long file paths/names

Question

I'm looking at handling longer file paths in my windows application.

Currently, I have a text box (edit box) in which a user can type an absolute file path. I then read that typed file path, using GetWindowText, into a string declared like so: TCHAR FilePath[MAX_PATH];

Obviously, here i'm relying on the MAX_PATH constant which limits me to 260 chars. So to handle longer file/paths names could I just extend my TCHAR array like this: TCHAR FilePath[32767];.

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

Thank you in advanced!

---

Here's the whole code snippet of what i mentioned above:

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

Answer 1

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

However, you can access longer paths - with certain limitations - by prefixing the path with "\\?\". However, the limitations of using the "\\?\" prefix usually outweighs the benefit:

1. There are a number of Win32 APIs that do no support paths with this prefix (for example, LoadLibrary will always fail on a path that is longer than 260 characters)
2. The Win32 Canonicalization rules do not take effect when using the "\\?\" prefix. For example, by default, "/" in paths is converted to "\", "." and ".." are converted into references to the current and parent directories respectively and so on: none of that happens when you use the "\\?\" prefix.
3. Just because you can modify your program to support longer paths, other programs may fail to open the files you've created. This will be the case if those other programs don't also use the "\\?\" prefix.

To be honest, point #2 is the real killer: you open yourself up to all sorts of trouble when using the "\\?\" prefix and you basically have to re-implement the Win32 canonicalization rules yourself if you go that route.

Therefore, my recommendation is to just stick with the 260 limitation. At least until there's better platform support for longer paths.