Re: PATCH: tail-dropping in files module mkdir

[Clint Adams <schizo@debian.org>]

> 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?

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.

> 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.  Therefore,
the absolute link from the root could not be as long as the longest
path on the referent filesystem.  Obversely, the BIGFS can probably handle
symlinks to the root fs.