zsh-workers
 help / color / mirror / code / Atom feed
From: Clint Adams <schizo@debian.org>
To: Bart Schaefer <schaefer@candle.brasslantern.com>
Cc: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: tail-dropping in files module mkdir
Date: Tue, 8 Aug 2000 07:40:07 -0400	[thread overview]
Message-ID: <20000808074007.A7961@dman.com> (raw)
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.


  reply	other threads:[~2000-08-08 11:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-08-04 14:53 Clint Adams
2000-08-04 15:17 ` Bart Schaefer
2000-08-04 15:32   ` Clint Adams
2000-08-04 16:10     ` Bart Schaefer
2000-08-05  0:40       ` Clint Adams
2000-08-04  7:02         ` PATCH: pathconf() again Bart Schaefer
2000-08-04 13:19           ` Clint Adams
2000-08-04 18:15             ` Bart Schaefer
2000-08-05  0:52               ` Clint Adams
2000-08-05  4:48                 ` PATCH: tail-dropping in files module mkdir Bart Schaefer
2000-08-07 18:04                   ` Clint Adams
2000-08-07 20:39                     ` Bart Schaefer
2000-08-08 11:40                       ` Clint Adams [this message]
2000-08-08 21:47                         ` Bart Schaefer
2000-08-09 14:25                           ` PATH_MAX vs. _PC_PATH_MAX vs. POSIX (was Re: PATCH: tail-dropping in files module mkdir) Clint Adams
2000-08-09 17:07                             ` Bart Schaefer
2000-08-09 17:51                             ` Bart Schaefer
2000-08-05  6:45           ` PATCH: pathconf() again Wayne Davison

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20000808074007.A7961@dman.com \
    --to=schizo@debian.org \
    --cc=schaefer@candle.brasslantern.com \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).