Zsh Mailing List Archive Messages sorted by: Reverse Date, Date, Thread, Author

Re: PATCH: tail-dropping in files module mkdir

X-seq: zsh-workers 12539
From: Clint Adams <schizo@xxxxxxxxxx>
To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: PATCH: tail-dropping in files module mkdir
Date: Fri, 4 Aug 2000 20:40:21 -0400
Cc: zsh-workers@xxxxxxxxxxxxxx
In-reply-to: <1000804161026.ZM28907@xxxxxxxxxxxxxxxxxxxxxxx>; from schaefer@xxxxxxxxxxxxxxxxxxxxxxx on Fri, Aug 04, 2000 at 04:10:25PM +0000
Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
References: <20000804105323.B4820@xxxxxxxx> <1000804151753.ZM28846@xxxxxxxxxxxxxxxxxxxxxxx> <20000804113220.A5135@xxxxxxxx> <1000804161026.ZM28907@xxxxxxxxxxxxxxxxxxxxxxx>

> It can just keep lopping the tail as long as (errno == ENOENT ||
> errno == ENOTDIR), I think.  There are some special cases involving paths

I was assuming that there would be non-mkdir cases where this
would result in the wrong filesystem being selected, but I can't
think of such a situation.

> 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().  Is subsuming
LGPL- or BSD-licensed code objectionable?

References:
- PATCH: tail-dropping in files module mkdir
  - From: Clint Adams
- Re: PATCH: tail-dropping in files module mkdir
  - From: Bart Schaefer
- Re: PATCH: tail-dropping in files module mkdir
  - From: Clint Adams
- Re: PATCH: tail-dropping in files module mkdir
  - From: Bart Schaefer

Messages sorted by: Reverse Date, Date, Thread, Author