Zsh Mailing List Archive
Messages sorted by:
Re: PATCH: tail-dropping in files module mkdir
- X-seq: zsh-workers 12566
- From: Clint Adams <schizo@xxxxxxxxxx>
- To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- Subject: Re: PATCH: tail-dropping in files module mkdir
- Date: Tue, 8 Aug 2000 07:40:07 -0400
- Cc: zsh-workers@xxxxxxxxxxxxxx
- In-reply-to: <000807133944.ZM26497@xxxxxxxxxxxxxxxxxxxxxxx>; from schaefer@xxxxxxxxxxxxxxxxxxxxxxx on Mon, Aug 07, 2000 at 01:39:44PM -0700
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <20000804113220.A5135@xxxxxxxx> <1000804161026.ZM28907@xxxxxxxxxxxxxxxxxxxxxxx> <20000804204021.A7925@xxxxxxxx> <1000804070216.ZM23696@xxxxxxxxxxxxxxxxxxxxxxx> <20000804091955.A4368@xxxxxxxx> <000804111549.ZM28988@xxxxxxxxxxxxxxxxxxxxxxx> <20000804205227.B7925@xxxxxxxx> <1000805044825.ZM29238@xxxxxxxxxxxxxxxxxxxxxxx> <20000807140445.A15891@xxxxxxxx> <000807133944.ZM26497@xxxxxxxxxxxxxxxxxxxxxxx>
> It doesn't really matter whether it has any significance for absolute paths.
It does when we're trying to predict whether or not the entirety of mkdir -p
Of course, it seems as though other mkdir implementations will mkdir()
all elements up to the failure point and happily leave them there, so
we'd be compatible if we removed the check.
> 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
Agreed. This is why I only touched the two places where PATH_MAX wasn't
being used for buffers.
> 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
I wonder if performance will suffer significantly from this.
> 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).
It could also conceivably fail if any of the directories to be made
have strlen(dirpart) > pathconf(dirpart,_PC_NAME_MAX), or if the
library is answering incorrectly on behalf of the kernel or other
> You're assuming an implementation that restricts the size of a symlink to
I was merely throwing out possibilities.
Anyway, I assume that we can throw out the pathmax checks in the files module.
I'd think we can do the same with the parameter module, since _PC_PATH_MAX
is essentially useless there too.
That just leaves buffers to be dynamically grown, AFAICT.
Messages sorted by: