>> In your specific example of a file name, most (all?) operating
>> systems already impose a limit to the length of a file name.
> I am sorry, but this this is complete and utter nonsense. MVS is one
> of the few systems that does impose such a limit and, even then, the
> limit is not as obvious as might appear. Unix has NO limit, and
> never has had.
I suggest you check your facts.
"file name" can mean (at least) two things: a directory entry (ie, a
single link in the filesystem tree) or an entire path name.
The former has always had a hard limit and likely always will. This
limit used to be (IIRC) 14 bytes under V7 and older SysV; FFS raised
this to 255. I have never seen it higher than 256; if you know of a
UNIX-alike with this limit higher than 255 I would love to hear full
details.
The documentation for 4.3 claimed there was a hard limit MAXPATHLEN on
the total length of a pathname - AFAICR I never verified this. But I
just looked at the NetBSD source and it (and by implication, probably
4.4 and almost all derivatives thereof) imposes a similar hard maximum,
again MAXPATHLEN (though I don't know whether the value differs between
4.3 and 4.4/NetBSD/etc). (Those of you who wish to verify this claim
for yourselves should look at namei(), in sys/kern/vfs_lookup.c, and
note the copystr/copyinstr call with an explicit MAXPATHLEN limit. The
version of vfs_lookup.c I'm looking at is 1.24.2.1; I believe this is
the 1.3 release version.)
In the NetBSD source tree I have handy, MAXPATHLEN is defined in
<sys/param.h> as PATH_MAX; PATH_MAX is defined in <sys/syslimits.h> as
1024. The limit of 255 on a path component length probably originally
came from the directory format, which reserves only one byte to store
that length; it is also imposed (for all filesystems, not just FFS) by
lookup(), also in vfs_lookup.c, which explicitly checks
if (cnp->cn_namelen > NAME_MAX) {
error = ENAMETOOLONG;
goto bad;
}
I also note the presence of _PC_PATH_MAX and _PC_NAME_MAX in the
pathconf() manpage. The manpage claims POSIX compliance, and I thus
have reason to think POSIX defines those, though I do not have a copy
of POSIX handy to check. But there is a strong implication that POSIX
expects such limits to exist (otherwise, why provide a way to query
them?), and if you can demonstrate the existence of anything even
vaguely UNIXish that does not impose hard and relatively small limits
on path and name length I would love to hear about it.
> PATH_MAX (and friends) under Unix is a lower bound on the length of a
> name that the system is required to support under all circumstances.
What is your authority for this statement? The only documentation I
have found on what PATH_MAX is is the comment in <sys/syslimits.h>,
which says simply "max bytes in pathname".
> But there are facilities that work with any length of name that they
> are supplied with.
Please give an example. (The example must, of course, use the string
as a pathname; calls such a strcpy() that manipulate strings without
treating them as pathnames are irrelevant here.)
der Mouse
mouseat_private
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:44:16 PDT