automake
[Top][All Lists]
Advanced

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

Re: bug in mkdir -p detection


From: Marc Espie
Subject: Re: bug in mkdir -p detection
Date: Wed, 30 Jan 2008 00:07:59 +0100
User-agent: Mutt/1.5.12-2006-07-14

On Wed, Jan 02, 2008 at 10:48:34PM +0100, Ralf Wildenhues wrote:
> 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
> free.
> 
> > > 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 <http://www.openbsd.org/cgi-bin/cvsweb/src/bin/mkdir/mkdir.c>.
> If you were involved in the process, then thanks for doing so.

Actually I just reopened the PR and submitted a distinct patch, since
the stuff that was committed was wrong for another reason.  Mainly, it calls
mkdir() needlessly on existing directories, which is raising hell with
tracing tools like systrace, which is going to report all the weird mkdir
that fail along the way...


Apart from that, that race is some stuff that wouldn't even hamper the
use of mkdir -p from Makefiles. We're talking about races betwen directories
and non-directories ! I see scenarios where this could happen, but no useful
and correct scenario when this will break a parallel build.

> > > 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.

I'm a bit annoyed at you about this.   I did not really look too closely
at this race, but having had to look at it for other reasons, this race
is *totally* unrelated to normal usage of mkdir -p. It will happen only
when someone uses 'mkdir -p path' and somebody else uses 'touch path' at
the exact same time. I totally fail to see the relevance to actual usage
scenarios of mkdir -p, even in parallel builds! especially in parallel
builds...

Unless I'm mistaken, the ac tests are supposed to detect actual problem, 
not theoretical issues that do not affect normal builds. <sarcasm>say, or 
you will start to reject function, because there is an unrelated bug in that 
function ? at that stage, about the only function that makes sense is 
abort(), as this one will never fail to break the current program... 
Even exit() sounds chancy</sarcasm>


Even with that caveat, two years is an incorrect amount of time to wait for.
one year at the most, preferably six months. Unlike, some other projects,
we have frequent releases. And the life-time of OpenBSD release is two cycles,
that is one year.  Anyone using an OpenBSD that they haven't upgraded in a
year is running an unsupported release.

Especially for development tools like autoconf/automake, it makes no sense
to extend that time. If anything, it should be shortened. People writing new
software should do so on current systems, unless they REALLY want to run
into old bugs, and by the time it's released, a few months have usually
elapsed. So, one year at the most.  If you insist on longer time frames,
you're doing your users a disservice by letting them continue to use
discontinued software... it's not as if the update isn't always available,
and as free as the original version.




reply via email to

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