Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
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
will fail.
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
> change.
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
> will.
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
limiting entities.
> 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:
Reverse Date,
Date,
Thread,
Author