> "file name" can mean (at least) two things: a directory entry (ie, a > single link in the filesystem tree) or an entire path name. Yes. In the context of buffer overflow, the latter is more usually relevant (as well as conforming to more traditional use). > 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. Sigh. That isn't the point. Many or most of the 14 character Unices allowed longer names, and truncated them quietly to fit, which is why POSIX explicitly allows that behaviour. I do not know if any 255 character Unices do, but I would expect so. Furthermore, think of a tar file created on a non-Unix system for unpicking on a Unix one, or what compress may do on a file with a 255-character name. A robust program has to allow for longer names being supplied to it, even if it can assume that it will not find them in a directory entry. > 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). ... How? Try creating a filing system with a 1000 character path name in it and mounting it in a directory with a 1000 character path name in another filing system. Are you seriously saying that the mount WILL fail? And, actually, you used to be able to do this simply by creating subdirectories under most Unices, though I haven't tried recently. And then think of symbolic links and what they imply .... > 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. I do, and I suggest that you look it up (and then run some experiments). pathconf() is required to return a value no lower than _PC_PATH_MAX, and may fail (which often happens for remote filing systems). Furthermore, POSIX explicitly permits _PC_PATH_MAX not to be defined and pathconf() to return -1 if the limits are essentially infinite (whatever that may mean). I don't know of any Unices that do this, but there may well be some. > > 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". POSIX.1 (1990). > > 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.) Anything that takes an argument and recurses down the path using chdir() rather than simply opening the pathname. And even opening the pathname MAY work on some Unices, as passing an overlong name to open() is not actually REQUIRED to fail. Nick Maclaren, University of Cambridge Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email: nmm1at_private Tel.: +44 1223 334761 Fax: +44 1223 334679
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:44:18 PDT