Re: sed bug version 4.0.9

[Paolo Bonzini]

> Ok, I know there should probably be some check if the input file is a
> directory as the above case, since it doesn't really make sense to do it
> like that. But in any case you might consider this diff.

Your patch actually cured the symptom but did not fix the problem.  The
problem is that we do not abort when the *read* fails.  Run with strace and
you'll see that read aborts with EISDIR (of course) but we do not care.  I
fixed it by creating wrappers in lib/utils.c for getline (which panics when it
finds an error) and most importantly mkstemp (so that panic will clear the
temporary files upon error).  This fixed other tempfile leakage bugs, for
example

   sed -i -e :a -e p -e ba filename

is an infinite loop which fills up the disk and cause an ENOSPC.  After this,
old seds would have panicked, and exited with the big big file still on disk.
The new version clears the temporary file when the error is emitted.

Since I was at it, I also added a wrapper for rename that optionally unlinks a
file if the renaming fails: this will yield better error messages (and not
leave tempfiles around) if there are races.  For example, if processing the
input takes a while, in the meanwhile one might do

  rm infile
  mkdir infile

or something like that.

Thanks for bringing the problem to me, and for analyzing it.

Paolo