From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29048 invoked from network); 7 Aug 2000 20:40:19 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 7 Aug 2000 20:40:19 -0000 Received: (qmail 24473 invoked by alias); 7 Aug 2000 20:40:00 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12560 Received: (qmail 24455 invoked from network); 7 Aug 2000 20:39:58 -0000 From: "Bart Schaefer" Message-Id: <000807133944.ZM26497@candle.brasslantern.com> Date: Mon, 7 Aug 2000 13:39:44 -0700 In-Reply-To: <20000807140445.A15891@dman.com> Comments: In reply to Clint Adams "Re: PATCH: tail-dropping in files module mkdir" (Aug 7, 2:04pm) References: <20000804105323.B4820@dman.com> <1000804151753.ZM28846@candle.brasslantern.com> <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> 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 7, 2:04pm, Clint Adams wrote: > Subject: Re: PATCH: tail-dropping in files module mkdir > > You misunderstand the problem. It isn't that we need the real path in > > order to determine the value of pathmax, it's this sort of silliness: > > > > /usr/local/../bin/../doc/../etc/../include/../lib/../local/blahblahblah > > > > If the length of the "blahblahblah" part approaches pathmax, you get an > > ENAMETOOLONG error even though you could chdir to each directory from > > left to right and eventually reach a legitimate file. Computing the > > realpath() in such a case won't change anything. > > Again I am confused. Does _PC_PATH_MAX have any significance for > absolute paths? Can someone check POSIX? It doesn't really matter whether it has any significance for absolute paths. 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. 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'm now of the opinion that the zpathmax check should be removed > from bin_mkdir, except for mkdir -p, in which case not only zpathmax > should be checked, but also _PC_NAME_MAX for each path element, including > the tail. That's equivalent to my alternate suggestion of simply letting domkdir() fail and examining errno to see whether we should break or continue as a result. The zpathmax() test is performed only so that the command does not give up on the first too-long argument when multiple arguments are present. Incidentally, I found an HP-UX pathconf() manpage on the web, which says: 4. If path or fildes does not refer to a directory, pathconf() or fpathconf() returns -1 and sets errno to EINVAL. So we may need to test EINVAL as well as ENOENT and ENOTDIR in zpathmax(). It goes on: 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? If so, we're wrong ever to compare strlen(dir) to zpathmax(dir). > > It would make sense that an absolute link from the root could be as long > > as the longest path on the filesystem to which the link refers, no? > > Well, let's say you have a BIGFS mounted on on /usr, where the > largest filename is 65,535 characters long. / is a SMALLFS, which > has a maximum filename size of 255 characters, and the maximum > size of the destination of a symlink is 1023 characters. You're assuming an implementation that restricts the size of a symlink to the size of a local filesystem path. But there doesn't need to be such a relationship -- the implementation could examine the link component by component until it finds the target filesystem, and then hand the rest of the interpretation off to the target driver. In that case there'd only be a problem if you didn't cross into a new filesystem within the first 1023 bytes. Traditional unix filesystems don't handle that, but so what?