From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5812 invoked from network); 8 Aug 2000 21:48:22 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 8 Aug 2000 21:48:22 -0000 Received: (qmail 12956 invoked by alias); 8 Aug 2000 21:48:09 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12573 Received: (qmail 12943 invoked from network); 8 Aug 2000 21:48:07 -0000 From: "Bart Schaefer" Message-Id: <000808144749.ZM7078@candle.brasslantern.com> Date: Tue, 8 Aug 2000 14:47:49 -0700 In-Reply-To: <20000808074007.A7961@dman.com> Comments: In reply to Clint Adams "Re: PATCH: tail-dropping in files module mkdir" (Aug 8, 7:40am) 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> <20000808074007.A7961@dman.com> X-Mailer: Z-Mail Lite (5.0.0 30July97) To: Clint Adams Subject: Re: PATCH: tail-dropping in files module mkdir Cc: zsh-workers@sunsite.auc.dk MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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.