Re: PATCH: tail-dropping in files module mkdir

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Aug 7,  2:04pm, Clint Adams wrote:
> Subject: Re: PATCH: tail-dropping in files module mkdir
> > You misunderstand the problem.  It isn't that we need the real path in
> > order to determine the value of pathmax, it's this sort of silliness:
> > 
> > /usr/local/../bin/../doc/../etc/../include/../lib/../local/blahblahblah
> > 
> > If the length of the "blahblahblah" part approaches pathmax, you get an
> > ENAMETOOLONG error even though you could chdir to each directory from
> > left to right and eventually reach a legitimate file.  Computing the
> > realpath() in such a case won't change anything.
> 
> Again I am confused.  Does _PC_PATH_MAX have any significance for
> absolute paths?  Can someone check POSIX?

It doesn't really matter whether it has any significance for absolute paths.
The primary use of the PATH_MAX constant in zsh is to determine the size of
a buffer to allocate for copying a path name.  Even if we use realpath() or
the equivalent to find the actual directory whose pathmax vaue we want, the
actual string that is going to be copied into the resulting buffer does not
change.

What this seems to imply is that we should always arbitrarily grow any
buffer that will hold a path name -- not even attempt to determine a
maximum size in advance -- and simply let the system calls fail when they
will.

> I'm now of the opinion that the zpathmax check should be removed
> from bin_mkdir, except for mkdir -p, in which case not only zpathmax
> should be checked, but also _PC_NAME_MAX for each path element, including
> the tail.

That's equivalent to my alternate suggestion of simply letting domkdir()
fail and examining errno to see whether we should break or continue as a
result.  The zpathmax() test is performed only so that the command does not
give up on the first too-long argument when multiple arguments are present.

Incidentally, I found an HP-UX pathconf() manpage on the web, which says:

           4.   If path or fildes does not refer to a directory, pathconf()
                or fpathconf() returns -1 and sets errno to EINVAL.

So we may need to test EINVAL as well as ENOENT and ENOTDIR in zpathmax().
It goes on:

           5.   If path or fildes refers to a directory, the value returned
                is the maximum length of a relative path name when the
                specified directory is the working directory.

Does this imply that (zpathmax("/") - 4 == zpathmax("/tmp")) is possible?
If so, we're wrong ever to compare strlen(dir) to zpathmax(dir).

> > It would make sense that an absolute link from the root could be as long
> > as the longest path on the filesystem to which the link refers, no?
> 
> Well, let's say you have a BIGFS mounted on on /usr, where the
> largest filename is 65,535 characters long.  / is a SMALLFS, which
> has a maximum filename size of 255 characters, and the maximum
> size of the destination of a symlink is 1023 characters.

You're assuming an implementation that restricts the size of a symlink to
the size of a local filesystem path.  But there doesn't need to be such
a relationship -- the implementation could examine the link component by
component until it finds the target filesystem, and then hand the rest of
the interpretation off to the target driver.  In that case there'd only
be a problem if you didn't cross into a new filesystem within the first
1023 bytes.  Traditional unix filesystems don't handle that, but so what?