bug#11377: configure.am - fails to remove configure before attempting replacement

[Eric Blake]

On 05/03/2012 05:47 PM, Ronald F. Guilmette wrote:
> In message <address@hidden>, you wrote:
> 
>> Nothing against your style of coding, but I do want to point out that
>> recommending anyone delete a file before rebuilding its contents is
>> racy.
> 
> I respectfully disagree.
> 
>> If things crash in the middle, you can be left without the file,
> 
> Yes.  So?  You still have the Makefile, which contains all of the instructions
> for re-making the file in question.
> 
>> or with a file with incomplete contents.
> 
> Could you please explain, for my edification, how inserting an initial `rm'
> would affect this possibility in any way whatsoever?  (Some examples might
> help to illustrate.)

See, for example, this autoconf patch:
http://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=e9cceec

Autoconf was generating code that created a cache file by writing
directly in to the target, and there were actual examples of failure in
the wild where it broke because of a partially written cache file with
incomplete contents and a current timestamp would not be regenerated to
be complete.  In fact, the problem was hit in practice so often that gcc
had resorted to a per-directory config.cache just to work around the
worst aspects of this failure mode.

We switched things over to writing to a temporary file and atomically
mv'ing it into place, and the bug disappeared.

> 
> I'm not even sure how one would generate a file with "incomplete contents",
> let alone how that process might or might not be in any way affected by an
> initial "rm target".

Any time you hit Ctrl-C in the middle of a make run, you might be
interrupting a process that is in the middle of writing contents to an
output file.

> In any event, the style of Makefile coding you are suggesting, wherein the
> final command to remake a given target would be something like:
> 
>       mv tempfile target
> 
> is not, I would suggest, at all widespread in current practice.

Agreed, but that doesn't mean that we shouldn't advertise it as being
safer than rm.

> 
> P.S.  Your suggestion that removing & replacing the contents of a given target
> file only at the very last second (and only in an atomic operation) is in some
> sense "best practice" assumes that something would, in fact, go wrong if
> the given target file were to be removed sooner, before being replaced.

Yes - in the case of autoconf's config.cache, things DO go wrong in a
subsequent build if config.cache is removed too soon (a partial file can
corrupt the build, and a missing file costs extra time to rebuild the file).

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature