Zsh Mailing List Archive
Messages sorted by:
Re: PATCH: tail-dropping in files module mkdir
- X-seq: zsh-workers 12545
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: Clint Adams <schizo@xxxxxxxxxx>
- Subject: Re: PATCH: tail-dropping in files module mkdir
- Date: Sat, 5 Aug 2000 04:48:25 +0000
- Cc: zsh-workers@xxxxxxxxxxxxxx
- In-reply-to: <20000804204021.A7925@xxxxxxxx>
- In-reply-to: <20000804205227.B7925@xxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <20000804105323.B4820@xxxxxxxx> <1000804151753.ZM28846@xxxxxxxxxxxxxxxxxxxxxxx> <20000804113220.A5135@xxxxxxxx> <1000804161026.ZM28907@xxxxxxxxxxxxxxxxxxxxxxx> <20000804204021.A7925@xxxxxxxx> <1000804070216.ZM23696@xxxxxxxxxxxxxxxxxxxxxxx> <20000804091955.A4368@xxxxxxxx> <000804111549.ZM28988@xxxxxxxxxxxxxxxxxxxxxxx> <20000804205227.B7925@xxxxxxxx>
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:
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
Bart Schaefer Brass Lantern Enterprises
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
Messages sorted by: