I know that (on Linux at least, with native file systems like Ext3) file paths can in theory be quite long, and
PATH_MAX is often (but not always) as big as 4096 (see this; and this explains it could be longer or runtime defined!).
However, file paths are often constructed on the fly, and it not uncommon in C to code something like
#define MY_PATH_MAX 256 char pathbuf[MY_PATH_MAX]; snprintf (pathbuf, sizeof(pathbuf), "%s/%s", getenv("HOME"), somevar); FILE *f = fopen(pathbuf, "r"); //// etc, avoiding error checks for simplicity
Now, I believe that having
MY_PATH_MAX being not too big (in particular to avoid consuming a lot of space on the call stack frame) is practically important and sensible. So, in the above example doing
#define MY_PATH_MAX PATH_MAX would be silly (no need to spend 4Kbytes in my call frame).
I'm coding since 1974 and I never met a case where a file path was larger than a screen width, e.g. 80 characters or so. All the file systems I heard about did not have very deep directory hierarchy (a file with 8 directories above it is very unusual).
So, is my intuition correct? Does real software care about such long or bizarre file paths? Likewise, I never met any file name containing a newline (and I strongly recommend against spaces in file names!).
IIUC, you won't be able to build a GNU software like GCC in a directory whose name contain spaces or newlines... very likely
autoconf related scripts would suffer.... Also, there is simply no way to give in your
$HOME containing newline or even a colon
: -since passwd(5) does not support it.
Is my practical limit of 256 bytes in a file path a good limit?
Per the comments, I just upgraded it to 384...
Do you have a practical example where long file path names are relevant? I'm mostly interested in POSIX or Linux systems!