winapi - Should I deal with files longer than MAX_PATH?

Question

Just had an interesting case.

My software reported back a failure caused by a path being longer than MAX_PATH.

The path was just a plain old document in My Documents, e.g.:

C:Documents and SettingsBillSome Stupid FOlder NameA really ridiculously long file thats really very very very..........very long.pdf

Total length 269 characters (MAX_PATH==260).

The user wasn't using a external hard drive or anything like that. This was a file on an Windows managed drive.

So my question is this. Should I care?

I'm not saying can I deal with the long paths, I'm asking should I. Yes I'm aware of the "?" unicode hack on some Win32 APIs, but it seems this hack is not without risk (as it's changing the behaviour of the way the APIs parse paths) and also isn't supported by all APIs .

So anyway, let me just state my position/assertions:

1. First presumably the only way the user was able to break this limit is if the app she used uses the special Unicode hack. It's a PDF file, so maybe the PDF tool she used uses this hack.
2. I tried to reproduce this (by using the unicode hack) and experimented. What I found was that although the file appears in Explorer, I can do nothing with it. I can't open it, I can't choose "Properties" (Windows 7). Other common apps can't open the file (e.g. IE, Firefox, Notepad). Explorer will also not let me create files/dirs which are too long - it just refuses. Ditto for command line tool cmd.exe.

So basically, one could look at it this way: a rouge tool has allowed the user to create a file which is not accessible by a lot of Windows (e.g. Explorer). I could take the view that I shouldn't have to deal with this.

(As an aside, this isn't an vote of approval for a short max path length: I think 260 chars is a joke, I'm just saying that if Windows shell and some APIs can't handle > 260 then why should I?).

So, is this a fair view? Should I say "Not my problem"?

UPDATE: Just had another user with the same problem. This time an mp3 file. Am I missing something? How can these users be creating files that violate the MAX_PATH rule?

Answer 1

It's not a real problem. NTFS support filenames up to 32K (32,767 wide characters). You need only use correct API and correct syntax of filenames. The base rule is: the filename should start with '\?' (see http://msdn.microsoft.com/en-us/library/aa365247(v=VS.85).aspx) like \?C:Temp. The same syntax you can use with UNC: \?UNCServersharePath. Important to understand that you can use only a small subset of API function. For example look at MSDN description of functions

CreateFile
CreateDirectory 
MoveFile

and so on

you will find text like :

In the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, call the Unicode version of the function and prepend "?" to the path. For more information, see Naming a File.

This functions you can safe use. If you have a file handle from CreateFile you can use all other functions used hFile (ReadFile, WriteFile etc.) without any restriction.

If you write a program like virus scanner or backup software or some good software running on a server you should write your program so, that all file operations support filenames up to 32K characters and not MAX_PATH characters.