zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: Clint Adams <schizo@debian.org>
Cc: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: tail-dropping in files module mkdir
Date: Sat, 5 Aug 2000 04:48:25 +0000	[thread overview]
Message-ID: <1000805044825.ZM29238@candle.brasslantern.com> (raw)
In-Reply-To: <20000804204021.A7925@dman.com>
In-Reply-To: <20000804205227.B7925@dman.com>

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   


  reply	other threads:[~2000-08-05  4:48 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                 ` Bart Schaefer [this message]
2000-08-07 18:04                   ` PATCH: tail-dropping in files module mkdir Clint Adams
2000-08-07 20:39                     ` Bart Schaefer
2000-08-08 11:40                       ` Clint Adams
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=1000805044825.ZM29238@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=schizo@debian.org \
    --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).