From: jwl@ferrari.cray.com (Jim Lynch) Subject: Re: POSIX nonconformance in pathconf(3) Date: 20 Apr 1993 23:41:05 GMT
In article <1r0cl1$4k@nz12.rz.uni-karlsruhe.de>, ig25@fg30.rz.uni-karlsruhe.de (Thomas Koenig) writes:
|> In writing a manpage for pathconf(3) (nothing like writing documentation
|> to get to know a system ;-) I've come across behaviour which I think may
|> be POSIX - nonconforming.
|>
|> A call to pathconf("/usr/foo/bar", _PC_NAME_MAX) function always returns
|> 255 (which is the value of NAME_MAX from <linux/limits.h>). According
|> to POSIX.1, it should return the maximum length of a filename the
|> process is allowed to create in "/usr/foo/bar".
|>
|> However, if "/usr/foo/bar" is a directory on a Minix filesystem, the
|> maximum file lenth is 14; longer filenames are silently truncuated.
|> (I'm not talking about the DOS filesystem; its inherent limitations
|> mean that it cannot be POSIX compatible).
|>
|> An application which relied on pathconf(3) to get the maximum length of
|> a filename would be in trouble, if it created two filenames which are
|> longer than 14 characters and only differ from the 15th character on.
Let me take a stab at this. First I think that you may be confusing the
maximum length of a file name with the maximum length of a path and filename.
What pathconf returns is the maximum length of a file name within the
file system. Not the file name and path combined. The reason for the first
argument in the call to pathconf is so that you can ask for the max length for
a specific path. As is demonstrated in Linux, you can have different maximum
lengths for the different file systems. For instance, you might have a root
file system that is a minix file system and /usr as ext2. Then the call to
pathconf("/",_PC_NAME_MAX) would return a different number from
pathconf("/usr/bin",_PC_NAME_MAX).
The difference is that the file system doesn't store the path in the file name
field. Did I sufficiently confuse everyone?
Bottom line, I think pathconf is working as define in the POSIX standard, but
I have been know to be wrong before, and unless I get killed going home
tonight, will be again.
|>
|> Fixes? I've thought of two, so far.
|>
|> First, it might just be possible to parse /etc/mtab, to see which kind
|> of file system "/usr/foo/bar" is mounted on. Ugly.
|>
|> Second, add two kernel functions, which return the limits associated
|> with a particular type of file system (one for fpathconf(), for file
|> descriptors, and the other for pathconf(), for path names). This would
|> require some additions to kernel data structures, such as storing the
|> maximum length of a filename for a file system somewhere it can be
|> accessed easily from an inode.
|>
|> Thoughts, anyone?
|> --
|> Thomas Koenig, ig25@rz.uni-karlsruhe.de, ig25@dkauni2.bitnet
|> The joy of engineering is to find a straight line on a double
|> logarithmic diagram.
Oh, UNICOS behaves in the same manner as Linux.
-- ======================================================================== Jim Lynch, Sales Analyst, Cray Research, Inc. / ARS: K4GVO Southeast District, Phone: (404) 631-2254, Email: jwl@sedist.cray.com Suite 270, 200 Westpark Drive, Peachtree City, GA 30269