It’s really an end case, some might claim. Though I find it irritating and I wanted to share it with you guys.
Nothing serious, I bet you know it. Well let’s get to the point then.
MAX_PATH_LEN or however it is exactly defined is 260. 260 bytes long to hold a path and everybody uses that. The thing is that under NTFS you can create really long paths (~32k), when each element (directory name or file name) has to be up to 250+something bytes, so you can chain a few easily as sub-directory and pass the 260 bytes limit.
I created a very long pathname using Python for ease:
import win32file
win32file.CreateDirectory(u"\\\\?\\c:\\01" + "2"*250, None)
win32file.CreateDirectoryW(u"\\\\?\\c:\\01" + "2"*250 + "\\" + "3"*250, None)
Then if you try to open it with explorer.exe you can enter only the first directory. Of course, you cannot browse the sub-directory, not even right click on it (you get the menu as if you right clicked on the background of the window) or delete it.. Explorer really acts weird with those directories.
Luckily RD /s always works, also fails in some cases. I was also trying to create many sub-directories and at some point it didn’t let me access to the lower sub-directory.
Now I ask myself, usually you ask the path length by passing a NULL instead of a buffer to the API, and this way you get the size, then you allocate that size and ask the data itself by a second call. Almost all Windows API work this way. So why support only 260 bytes full path name? Maybe it’s not practical to have that long file names? Even if it doesn’t, you are supposed to malloc already for the second call anyway… so it turns out people are just lazy and supply a buffer of 260 bytes and that’s it for first call and go.
One note though:
when I say 260 bytes, in reality it’s 260*2 bytes, cause NTFS stores the names in Unicode.
Waiting for someone to tell me I am wrong about the whole issue.
There was a problem in VAX/VMS where multiple accesses to different files in a directory that contained lots of files would really thrash the computer. It happened because there was a directory entry cache and when the number of files got large, many of the accesses to the directory would not be in the cache.
I’ve wondered if this is the same in Windows NT (2000, XP, …) since the architect of VMS also architected NT (and it does seem like directories with many files are slower)?
Well, with all due respect to Dave Cutler, I am not sure if it has anything to do with him. The worst thing about NTFS that everybody suffers from is that it’s a POSIX compliant. Which means they had to support short file names in NTFS itself (so I am not sure if it’s slower, though you will need more queries/memory), rather than a better usermode emulation layer for converting the names. But then, the kernel itself doesn’t need to convert the short names to longer ones, it can pass down the path as is. The problem is with other FS filter drivers and the such, that have to convert the short path to long one in order to track it down better… I bet you can bypass some anti-virtus checks with short paths.