illumos gate

I spent a lot of time looking into the right way to determine the maximum filename size on an operating system, and the approaches that many people use.

I learned the following:

1. FreeBSD and other BSDs apparently use MAXNAMLEN in dirent.h to indicate the maximum filename size (which they define to 255). Because we didn't have NAME_MAX in our header files for a while, a lot of programmers familiar with BSD mistakenly assumed illumos/Solaris uses MAXNAMLEN. They started including dirent.h and told people we use the "BSD version" of NAME_MAX (which is absurd because Solaris is clearly System V-based). The thing is, MAXNAMLEN on Solaris in dirent.h does exist and is said to indicate a filename size, but it's 512. So anyone using that will get a program that mistakenly believes we support 512 character filenames, and most of those people will be people who think they "fixed" the issue with us not supporting NAME_MAX.

2. Almost every operating system in use today at all uses a value of 255. MacOS X, OS/2, Solaris, FreeBSD, AIX, HPUX, Linux, Windows (though you do have a path name limit of 260 on there), and even BeOS. All of them have a maximum filename size of 255.

3. There's a lot of confusion about how to find the maximum filename length a system supports because there just aren't enough operating systems that support a different length to keep programmers on their toes. Many people wrongly think the value of NAME_MAX in limits.h is the correct place to look, and even the people who correct them wrongly think the correct constant is _POSIX_PATH_MAX because that's a constant defined to be 255 on most Unix systems. But _POSIX_PATH_MAX just happens to be 255 by accident, it has nothing to do with the length of a filename. It's the maximum path length required by POSIX. The reason no one ever encounters a failure is because there are almost no exceptions even though POSIX technically allows that number to be smaller or larger. It looks like the correct approach is actually to use pathconf with _PC_NAME_MAX to test what the configured value is for the filesystem you'll be installing the program on, but I rarely see that method used because almost every filesystem (other than MS-DOS/FAT) just uses 255.

4. POSIX only requires systems to support a NAME_MAX of 14 characters, but every modern system supports more than that. It's actually the XOPEN standard that requires a minimum filename size of 255 characters, and likely part of the reason why so many operating systems settled on it. _XOPEN_NAME_MAX actually is 255, but it works less often than _POSIX_PATH_MAX because fewer systems happen to have it defined in their header files.

So based on all that, and the fact that we did finally relent and let the confused programmers use NAME_MAX in limits.h (despite it being bad practice), could we do the same thing with MAXNAMLEN and just define that to 255? I understand we might be using the 512 for something, but I'm not sure what (it's definitely not filename size). Because let's face it, as much as we might want to adhere to standards, you could pretty much support every operating system in use today by just using a constant of 255 and it almost doesn't matter how you get that number. Until that changes, bad programming practices and mistaken information are going to be the rule rather than the exception.

Best thing we can do for now is try and make sure that whatever crazy method programmers want to use to get a 255 constant from the system headers without having to define it themselves, it won't break on our system. There's no reason to die on that hill when every OS seems to agree on this internally and it's just programmers who are confused about how to get the value everyone already agrees on.