Re: metamail: wishlist bug

[Michael Moerz <aon.912411198@aon.at>]

On Mon, Nov 27, 2000 at 03:37:16AM +0100, Jorgen Schaefer wrote:
> Michael Moerz <aon.912411198@aon.at> writes:
> 
> > The problem is that metamail makes use of mkstemp and it leaves
> > tmp files behind
> > [...]
> > 1) I could add each tmp file to a list and clean it up before the
> >    program leaves. (that would not require to touch even a single
> >    line of code, but I would have to add some lines that do that)
> > 2) I could change the mkstemp code to use tmpfile(), but then I
> >    would have to change much more of the original code and it 
> >    would be much more likely to introduce new bugs.
> 
> 3) Call unlink(2) or remove(3) on each file returned by mkstemp.
>    This assumes that metamail doesn't need to reference the file
>    by name lateron again.
> 
That's a nice idea, but the mkstemp function is called in a
function called MkTmpFileName. That function opens a file 
with a mm.XXXXXX name, closes it and returns it (the empty 
file is still in place). After that procedure the file is
used and hence therefore removed after using or it is not
used to and never removed. So all files that get filled with
mime-content get properly removed. But there are also other
tmpfiles created that have no obvious reason for me to exist.
If I would do as you suggest, I would have to debug !!!! the
whole metamail but not only with one mime-multipart email, but
with at least a dozen. Still then I wouldn't be able to determine
that I am making the call to unlink at the proper place.
If you want to prove that behaviour just invoke metamail with
any mime multipart message.

To be true before I make an other clutch like using unlink
(that is currently used throuought the program) I would rewrite
all tmpfile stuff to fit 2) since tmpfile() should never run out
of names, is better than mkstemp, and it's files are removed 
at the termination of the program.

-- 
kind regards,
Michael Moerz