[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug in mkdir -p detection

From: Ralf Wildenhues
Subject: Re: bug in mkdir -p detection
Date: Wed, 2 Jan 2008 22:48:34 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Hello Marc,

Thanks for the report.

* Marc Espie wrote on Thu, Dec 27, 2007 at 05:29:37PM CET:
> On Thu, Dec 27, 2007 at 05:25:56PM +0100, Marc Espie wrote:
> > the mkdir -p macro arbitrarily restricts itself to GNU mkdir by passing
> > it a --version.

Not arbitrarily.

> > This is a bit offensive.

No, it is defensive: that's a mkdir implementation known to be race

> > On OpenBSD, this particular issue does not exist.
> > It was fixed 8 years ago, published as OpenBSD 2.4, and all newer
> > versions are not affected.

Oh well, OpenBSD mkdir had a different race I reported 18 months ago
(PR user/5141).  It seems someone fixed it in OpenBSD's CVS just today,
see <>.
If you were involved in the process, then thanks for doing so.

> > Could we get an OS test and use mkdir on OpenBSD >= 2.4, please ?

Maybe two years after an OpenBSD release is out that has the above issue
fixed.  I suppose though that the added complexity of pulling in the
AC_CANONICAL_BUILD tests is not worth the trouble.

> Turns out the install_sh -d stuff is NOT safe in parallel mode, it errors out
> while trying to create a directory that already exists.

Now, this is interesting.  Could you provide the script_version of the
install-sh script of the package that exposes this, and also a 'make -jX'
output of a failure?  Ideally, I'd like to see a 'set -x' output of the
script failure, but don't bother if it's difficult to expose the race
that way.

Note there was a race condition present inside install-sh which was
fixed on 2006-05-11; this race could lead to a failure if -m is used
and the mode change is required in order for a subsequent mkdir to
have sufficient privileges to create an inner directory.  See
and references therein for the discussion.  Since you don't mention
privilege problems, I assume it is unrelated to the issue you observed.

> In general, most autoconf/automake tests DO set a cache entry, and you
> can later rely on that entry. This can be useful for package builders:
> we could very easily force configure to use mkdir -p, if we know we've
> got a safe one. But no, this test is done again and again for each
> configure entry.

With Autoconf >= 2.60 and Automake >= 1.10, this test is done by the
Autoconf macro AC_PROG_MKDIR_P, and you can use the variable $MKDIR_P
(and the cache variable is ac_cv_path_mkdir).  'install' is searched 
for by AC_PROG_INSTALL, overridden by $INSTALL, and cached in

Hope that helps.  Happy New Year.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]