Re: replace autom4te output file atomically

[Ralf Wildenhues]

* Ben Pfaff wrote on Thu, Aug 21, 2008 at 07:47:27AM CEST:
> Eric Blake <address@hidden> comments:
> > That's true of any program that uses temporary files; it seems
> > like documentation is the right solution (since you obviously
> > can't hook SIGKILL to do cleanup).  This could be as simple as
> > adding a statement that autom4te honors $TMPDIR (defaulting to
> > /tmp), and uses the namespace am4t* within that directory.
> > Hmm, the manual doesn't even have an instance of @env{TMPDIR}.
> 
> My patch, as submitted, does not in fact honor $TMPDIR or use
> /tmp.

I sense a misunderstanding here.  autom4te uses $TMPDIR (through $tmp)
with or without your variable (look at --verbose output to see that),
while m4 expands the input.  Only later, quadrigraph substitution reads
$tmp/output.0t and writes to what your patch chooses.

> It uses the same directory as the output file.  This was a
> conscientious choice, though not one that I mentioned: when /tmp
> is a separate file system, as it often is, it would then be
> pointless to try to atomically rename the new file over the old,
> since rename does not work across file systems.

Certainly.

> An alternative approach would be to simply delete the output file
> when autom4te terminates due to a signal.  This would also
> accomplish the original purpose of not leaving partially created
> configure scripts.

Unless, again, QUIT or KILL happen, of course.

> At the same time, it avoids the problems of
> atomic replacement and in particular the problem of leaving
> temporary file droppings upon SIGKILL etc.  Finally, the
> implementation is simpler.

I'm kind of wondering whether this is not still overkill.
If you run autoconf interactively, you certainly won't package
that result by accident.  If 'make' runs it, it will remove the
output file when interrupted.  If some other script runs it,
it should also honor the error.

Besides, I have a hard time believing that incomplete configure
scripts can somehow trick the developer into thinking that they
run successfully.  They don't create their output files correctly,
so 'make' should indicate to you that things are not as they should
be.

That said, I don't mind much.  The new patch looks a bit safer just
by way of being simpler, both patches lack a documentation update
(NEWS and autoconf.texi).

Cheers,
Ralf