From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <binutils-return-68938-listarch-binutils=sources.redhat.com@sourceware.org>
Received: (qmail 31957 invoked by alias); 2 Dec 2010 18:32:40 -0000
Received: (qmail 31946 invoked by uid 22791); 2 Dec 2010 18:32:39 -0000
X-SWARE-Spam-Status: No, hits=-1.8 required=5.0	tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE
X-Spam-Check-By: sourceware.org
Received: from mailout-de.gmx.net (HELO mail.gmx.net) (213.165.64.22)    by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Thu, 02 Dec 2010 18:32:35 +0000
Received: (qmail invoked by alias); 02 Dec 2010 18:32:31 -0000
Received: from xdsl-78-35-49-66.netcologne.de (EHLO localhost.localdomain) [78.35.49.66]  by mail.gmx.net (mp030) with SMTP; 02 Dec 2010 19:32:31 +0100
Received: from ralf by localhost.localdomain with local (Exim 4.69)	(envelope-from <Ralf.Wildenhues@gmx.de>)	id 1PODxH-0004Je-K2; Thu, 02 Dec 2010 19:32:31 +0100
Date: Thu, 02 Dec 2010 18:32:00 -0000
From: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: binutils@sourceware.org
Subject: Re: PATCH: PR binutils/12283: bfd/doc doesn't support parallel build
Message-ID: <20101202183231.GD16143@gmx.de>
References: <20101202170032.GA19376@intel.com> <20101202180829.GA16143@gmx.de> <AANLkTikDiv+z6DtpZ8DT64gKDtcxsdycJVdNwbExCs7-@mail.gmail.com> <20101202182050.GB16143@gmx.de> <20101202182235.GC16143@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20101202182235.GC16143@gmx.de>
User-Agent: Mutt/1.5.20 (2010-08-04)
X-IsSubscribed: yes
Mailing-List: contact binutils-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <binutils.sourceware.org>
List-Subscribe: <mailto:binutils-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/binutils/>
List-Post: <mailto:binutils@sourceware.org>
List-Help: <mailto:binutils-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: binutils-owner@sourceware.org
X-SW-Source: 2010-12/txt/msg00086.txt.bz2

* Ralf Wildenhues wrote on Thu, Dec 02, 2010 at 07:22:35PM CET:
> * Ralf Wildenhues wrote on Thu, Dec 02, 2010 at 07:20:50PM CET:
> > * H.J. Lu wrote on Thu, Dec 02, 2010 at 07:16:07PM CET:
> > > Failure is very random. There is a race condition. "make -j8" on a 16core
> > > machine can start making $(MKDOC) at the same time. How can move-if-change
> > > be 100% atomic?
> > 
> > Well, 'mv -f' within a mount point is atomic, that's how.
> 
> Ahh, move-if-change is broken: it doesn't ignore mv -f failure when the
> target is equal.  Let's fix move-if-change.

Does this alternative (untested) patch fix the race?

Thanks,
Ralf

ChangeLog:
2010-12-02  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	PR binutils/12283
	* move-if-change: Ignore failure of 'mv -f' if the destination
	is equal to the source afterwards.

diff --git a/move-if-change b/move-if-change
index ff74a55..1d2dd09 100755
--- a/move-if-change
+++ b/move-if-change
@@ -4,6 +4,8 @@
 
 usage="$0: usage: $0 SOURCE DEST"
 
+cmpprog=${CMPPROG-cmp}
+
 case $# in
 2) ;;
 *) echo "$usage" >&2; exit 1;;
@@ -18,5 +20,8 @@ done
 if test -r "$2" && cmp -s "$1" "$2"; then
   rm -f "$1"
 else
-  mv -f "$1" "$2"
+  if mv -f "$1" "$2"; then :; else
+    # Ignore failure due to a concurrent move-if-change.
+    $cmpprog "$1" "$2" >/dev/null 2>&1
+  fi
 fi