On 05/03/2012 05:47 PM, Ronald F. Guilmette wrote: > In message <4fa30527.8070...@redhat.com>, 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 ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
