Re: PATCH: tail-dropping in files module mkdir

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Aug 8,  7:40am, Clint Adams wrote:
>  
> >            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?
> 
> I believe it does.
> 
> > If so, we're wrong ever to compare strlen(dir) to zpathmax(dir).
> 
> Not if 'dir' is a relative, multi-directory path being passed to
> mkdir -p.  That could conceivably fail if strlen(dir) > zpathmax(dir).

What I mean is:

The definition of pathconf(dir, _PC_PATH_MAX) is inherently incompatible
with the definition of the PATH_MAX constant.  The latter is the maximum
length of an absolute path from the root [*], the former approximates the
same constant minus the length of [the equivalent of] realpath(dir).

Suppose pathconf() returns a constant value == _POSIX_PATH_MAX no matter
what its directory argument is.  Comparing strlen(realpath(dir)) to that
constant tells you if the filesystem will ultimately reject the name, but
comparing strlen(dir) tells you nothing.

Now suppose pathconf() returns a differing amount depending on the length
of realpath(dir).  In this case comparing strlen(realpath(dir)) to that
value is entirely wrong, because pathconf() has already accounted for the
real path!  Even comparing strlen(dir) doesn't tell you anything, because
what the value reflects is how much *more* path space you have left after
you already have used whatever it takes to get to realpath(dir), whereas
strlen(dir) gives some fraction of the already-used path space.

If somebody with access to the POSIX spec can refute that last paragraph,
I'll be thrilled.

In the meantime, we have to detect the constant-valued pathconf() in order
to determine whether we should do a comparison, because comparing to a
context-dependent pathconf() value is wrong.

> > 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 wonder if performance will suffer significantly from this.

Hard to say.  It's going to take a LOT of rewriting; it might be better
not even to pretend to support pathconf() until that rewriting is done.

[*] Or at least zsh has always treated it as if that's the definition.