From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2129 invoked from network); 5 Aug 2000 04:48:56 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 5 Aug 2000 04:48:56 -0000 Received: (qmail 8571 invoked by alias); 5 Aug 2000 04:48:47 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12545 Received: (qmail 8564 invoked from network); 5 Aug 2000 04:48:44 -0000 From: "Bart Schaefer" Message-Id: <1000805044825.ZM29238@candle.brasslantern.com> Date: Sat, 5 Aug 2000 04:48:25 +0000 In-Reply-To: <20000804204021.A7925@dman.com> Comments: In reply to Clint Adams "Re: PATCH: tail-dropping in files module mkdir" (Aug 4, 8:40pm) 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> In-Reply-To: <20000804205227.B7925@dman.com> Comments: In reply to Clint Adams "Re: PATCH: pathconf() again" (Aug 4, 8:52pm) X-Mailer: Z-Mail (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 4, 8:40pm, Clint Adams wrote: } Subject: Re: PATCH: tail-dropping in files module mkdir } } > There are some special cases involving paths } > that contain "../" that I'm a bit worried about, but I think most of } > those (and paths with lots of consecutive slashes) would fail zsh's } > constant-PATH_MAX tests already in boundary cases, so probably nothing } > will become broken that wasn't already. } } I suggest a compat.c wrapper around realpath(). 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. There's one other problem with that sort of path; if you do mkdir -p /usr/mountpoint/newdir1/../../newdir2/blahblahblah then the pathmax is that of /usr/mountpoint, but newdir2/blahblahblah is under /usr. realpath() is going to fail with ENOTDIR in that case, so again it doesn't help; and if newdir1 already exists, then pathconf() itself will discover that /usr/mountpoint/newdir1/../.. refers to /usr. Or at least I hope it will, or this is almost a waste of time. On Aug 4, 8:52pm, Clint Adams wrote: [About determining a buffer size for readlink()] } } > Only if it's a relative rather than absolute link. } } I don't understand the significance. 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? But a relative link has to be concatenated with the path to the directory containing it in order to resolve the link, so it couldn't be longer than the longest path on the filesystem of the containing directory. However, I don't actually know how this works in the kernel and/or the FS drivers. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net