On Mon, Nov 27, 2000 at 03:37:16AM +0100, Jorgen Schaefer wrote: > Michael Moerz <[EMAIL PROTECTED]> 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
