http://hg.mozilla.org/releases/mozilla-aurora/rev/5c4189019bc1 (I don't know what comm-central revision it is) I recently lost my TB profile, so I'm redownloading all messages from a pop3 server. There is over some 36 thousands emails. I noticed that after some 5000 email aprox. had been downloaded, the process slowed rapidly down. At some 15000 email each mail takes about 1 second to download. nsPop3Sink::IncorporateBegin is the culprit. It call CreateUnique to create a temp download file. Problem is that from some reason the prior temp files are not deleted. I have no idea how nsPop3Sink exactly works, but both places where m_tmpDownloadFile->Remove(false) is called are not hit.
Looks like if (m_pop3ConData->last_accessed_msg >= m_pop3ConData->number_of_messages) at nsPop3Protocol::GetMsg() never passes... I get back to this, if this is not known or someone else doesn't take, what I would prefer, later next week maybe. Till that time I'll delete the temp files manually....
oh, interesting. I should fix that.
Can you tell us what are the names of the temp files? What is the pattern? There are still several of these "not cleaning temp files"-bugs open but they did presumably happen at other actions of TB (not POP3 download).
(In reply to :aceman from comment #3) > Can you tell us what are the names of the temp files? What is the pattern? newmsg, and as CreateUnique creates, followings are newmsg-1, newmsg-2 ... newmsg-999. > There are still several of these "not cleaning temp files"-bugs open but > they did presumably happen at other actions of TB (not POP3 download). This is specific to POP3 as I understood the code. It still happens, I still have to delete the files manually. Just a reminder: this happens on a fresh profile. I use global inbox for the account. At the times I was able to reproduce this there were just a single pop3 account.
Good, so it is another type of temp files and are not covered by bug 299655.
Created attachment 611620 [details] [diff] [review] proposed fix with unit test Ghe quarantining stuff works by creating one temp file per get new mail session and re-using it by truncating it for every message downloaded, but we were creating a tmp file for every message. I probably messed this up during the pluggable store work. This fixes the leak, and adds a unit test.
we'll want this fix landed pretty soon on all branches.
fixed on trunk - http://hg.mozilla.org/comm-central/rev/27aac7b2e676 I'll transplant to branches in a minute.
fixed for beta - http://hg.mozilla.org/releases/comm-beta/rev/dd4c013f2477 aurora - http://hg.mozilla.org/releases/comm-aurora/rev/b022aa765e51