In the win32 layer Casey makes a comment about using MAX_PATH to allocate a buffer that is large enough to hold a file path. He's saying that: "Never use MAX_PATH in code that is user-facing". I'm wondering what that means exactly.

Does that mean that in a library function that returns a path, the size of the buffer should be passed in as an input (instead of assuming MAX_PATH)?

Does it also mean that the limit doesn't apply, i.e., a path can be longer than MAX_PATH?

I was also wondering about what the best practice is for manipulating paths. If you have to combine two paths in a local variable would you allocate a buffer of size MAX_PATH to hold the combined path?

I haven't watched few latest videos, but MAX_PATH is not the best thing to use when dealing with Windows paths. MAX_PATH is 260, but Windows can support up to 32767 long path. To do that you need to use UNC syntax. Instead of "C:\blabla\file.txt" you write "\\?\C:\blabla\file.txt". Of course, you don't need to present "\\?\" prefix to user, just prepend it to strings when passing to file API functions.

Here's more info on this: https://msdn.microsoft.com/en-us/...ary/windows/desktop/aa365247.aspx

Yes, all I meant here was that MAX_PATH is a fine thing to rely on if you are only talking about code that you are using for yourself. But if you are going to ship code where a Windows user might be entering in general pathnames, like with UNCs or to devices or NTFS or whatnot, MAX_PATH is not sufficient to hold the longest possible name, and so you can't use it like that.

- Casey

Especially if the software will be used in enterprise situations with 20 level deep directory structure each with nice long "descriptive" names.

Thanks for the answers!

I actually thought about this exact thing when I was making a file synchronizer for my self and I thought why not supporting long paths (longer than MAX_PATH) it seemed to me like a good idea at the time. But it was not.

The first thing that you will find shocking, is Windows Explorer itself cannot handle them. Yes, it is true. You cannot delete, move, rename or copy files whose path is longer than MAX_PATH. The applications that will operate on them are more likely not to handle them also.

It very easy to make by accident. just make very long nest of folders that is around MAX_PATH length then rename one of the parent folders to a name that is a little bit longer.
It is very frustrating if you got one by accident and you don't know what to do with it. I have a little c program that will call DeleteFileW with '\\?\' prefix, to delete one of these.

On the programming side, in order to use the prefix '\\?\', you have to use the Unicode version of the windows API which is UTF16. Now, you either have to convert UTF8 <-> UTF16 back and forth all the time which is cleaner but more expensive or you have to use UTF16 every where which is a mess and platform dependent.

I actually picked the later approach because I didn't care about other platforms and I thought converting UTF8 <-> UTF16 is expensive. But now I think about it, the first approach would have been better.

Since Windows Explorer cannot work with them, Why bother?!
Just throw an error message and let the user handle that since he have to deal with it any way.