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
next prev parent 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).