From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3163 invoked from network); 8 Aug 2000 11:40:59 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 8 Aug 2000 11:40:59 -0000 Received: (qmail 2285 invoked by alias); 8 Aug 2000 11:40:30 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12566 Received: (qmail 2278 invoked from network); 8 Aug 2000 11:40:29 -0000 Date: Tue, 8 Aug 2000 07:40:07 -0400 From: Clint Adams To: Bart Schaefer Cc: zsh-workers@sunsite.auc.dk Subject: Re: PATCH: tail-dropping in files module mkdir Message-ID: <20000808074007.A7961@dman.com> References: <20000804113220.A5135@dman.com> <1000804161026.ZM28907@candle.brasslantern.com> <20000804204021.A7925@dman.com> <1000804070216.ZM23696@candle.brasslantern.com> <20000804091955.A4368@dman.com> <000804111549.ZM28988@candle.brasslantern.com> <20000804205227.B7925@dman.com> <1000805044825.ZM29238@candle.brasslantern.com> <20000807140445.A15891@dman.com> <000807133944.ZM26497@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <000807133944.ZM26497@candle.brasslantern.com>; from schaefer@candle.brasslantern.com on Mon, Aug 07, 2000 at 01:39:44PM -0700 > 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.