http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5444
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
------- Additional Comments From [EMAIL PROTECTED] 2007-05-05 02:45 -------
I see the same behaviour. The tmpfiles are not really left behind, they just
stay there for quite a long time, in my case many hours.
>From what I found the the issue comes from the following lines in Message.pm:
# If the part type is not one that we're likely to want to use, go
# ahead and write the part data out to a temp file -- why keep sucking
# up RAM with something we're not going to use?
#
if ($msg->{'type'} !~ [EMAIL PROTECTED](?:text/(?:plain|html)$|message\b)@) {
my $filepath;
($filepath, $msg->{'raw'}) = Mail::SpamAssassin::Util::secure_tmpfile();
if ($filepath) {
# The temp file was created, add it to the list of pending deletions
# we cannot just delete immediately in the POSIX idiom, as this is
# unportable (to win32 at least)
push @{$self->{tmpfiles}}, $filepath;
$msg->{'raw'}->print(@{$body});
}
}
# if the part didn't get a temp file, go ahead and store the data in memory
if (!exists $msg->{'raw'}) {
$msg->{'raw'} = $body;
}
Simply commenting out the first section of the code makes those tempfiles not
appear, so I know the problem is here. From what I understand the tmpfile here
is created but only removed when the process terminates, to overcome the
inability of win32 to unlink an open file. Maybe there is still a more elegant
solution than keeping those file on disk for a long time.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
