MAXNAMELEN vs MAXNAMLEN
Rich Teer
I have a reconcilliation type of question. <sys/param.h>
says this:
/*
* MAXPATHLEN defines the longest permissible path length,
* including the terminating null, after expanding symbolic links.
* MAXNAMELEN is the length (including the terminating null) of
* the longest permissible file (component) name.
*/
#define MAXPATHLEN 1024
#define MAXNAMELEN 256
Whereas <dirent.h> says this:
#define MAXNAMLEN 512 /* maximum filename length */
So, one header file claims that the maximum length of
a file name (i.e., pathname component) is 256 characters,
and another claims that it is 512.
Shouldn't these two values be the same? I mean, how can
a UFS file system support 512 character file names when
the system itself is restricted to 256? (Or am I missing
something here?)
TIA,
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
Casper H.S. Dik
>Whereas <dirent.h> says this:
>#define MAXNAMLEN 512 /* maximum filename length */
That seems to be internal to the library readdir implementation;
still looks wrong, though.
>So, one header file claims that the maximum length of
>a file name (i.e., pathname component) is 256 characters,
>and another claims that it is 512.
>Shouldn't these two values be the same? I mean, how can
>a UFS file system support 512 character file names when
>the system itself is restricted to 256? (Or am I missing
>something here?)
The actual supported maximum length is filesystem dependent and
should be inquired using pathconf(file, _PC_NAME_MAX)
Casper
lvi...@yahoo.com
According to Rich Teer <rich...@rite-group.com>:
: <sys/param.h>
:says this:
:
:#define MAXNAMELEN 256
:
:Whereas <dirent.h> says this:
:
:#define MAXNAMLEN 512 /* maximum filename length */
In case someone is interested, dirent.h says this:
#if defined(__EXTENSIONS__) || \
(!defined(_POSIX_C_SOURCE) && !defined(_XOPEN_SOURCE))
#define MAXNAMLEN 512 /* maximum filename length */
So dirent.h is defining info for an extension or for code which
does not have POSIX_C_SOURCE or _XOPEN_SOURCE defined.
Since in most cases, these defines are not going to be present,
including the two header files will most often attempt to define
the same symbol with two different values...
Seems like a problem to me...
--
<URL: http://wiki.tcl.tk/ > In God we trust.
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >
Rich Teer
> In case someone is interested, dirent.h says this:
>
> #if defined(__EXTENSIONS__) || \
> (!defined(_POSIX_C_SOURCE) && !defined(_XOPEN_SOURCE))
>
> #define MAXNAMLEN 512 /* maximum filename length */
>
>
> So dirent.h is defining info for an extension or for code which
> does not have POSIX_C_SOURCE or _XOPEN_SOURCE defined.
Yep.
> Since in most cases, these defines are not going to be present,
> including the two header files will most often attempt to define
> the same symbol with two different values...
Nope. MAXNAMLEN and MAXNAMELEN are two different symbols,
not two the same with a typo! :-)
Fortunately, I've received email from Sun engineers resolving
this discrepancy.
Frank Cusack
> Fortunately, I've received email from Sun engineers resolving
> this discrepancy.
Fortunately for you, not for us! Spill it.
/fc
Rich Teer
My mistake: I didn't receive an email. I was thinking of
Casper's posting a few days ago (it's on groups.google.com).
Here's the gist of what he said:
That seems to be internal to the library readdir implementation;
still looks wrong, though.
The actual supported maximum length is filesystem dependent and
should be inquired using pathconf(file, _PC_NAME_MAX).
HTH,