问题
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);
回答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:
- There are a number of Win32 APIs that do no support paths with this prefix (for example,
LoadLibrarywill always fail on a path that is longer than 260 characters) - 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.
- 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.
回答2:
It depends on what kind of program you're writing. My own strategy has usually been to restrict path creation to MAX_PATH in length, but be able to read existing data from longer paths (using the "\\?\" prefix Dean mentions in his answer). There are exceptions to that though -- just for example, a backup program should accept long paths, and must reproduce exactly what it was given as input.
While Dean is certainly correct that Windows does not canonicalize longer paths for you, I have not found this to be much of a concern as a general rule. This doesn't generally mean writing your own code to canonicalize the path either -- it generally means having the user enter paths in a way that simply don't generate such things in the first place.
回答3:
No, because if you get a longer path, Windows can't accept it. So while technically, you could hold more chars than that in your buffer, you could never actually use the filepath result.
来源：https://stackoverflow.com/questions/3277717/c-winapi-handling-long-file-paths-names