Closed Bug 299655 Opened 20 years ago Closed 13 years ago

/tmp files left behind, some world-readable

Categories

(MailNews Core :: Composition, defect)

1.7 Branch
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 15.0

People

(Reporter: BenB, Assigned: hiro)

Details

Attachments

(1 file, 1 obsolete file)

Looking at my /tmp/ under Mac OS X, using Thunderbird 1.0.2, I see a great number of temp files that are left behind (no Thunderbird running atm), list below. All of them contain email msgs, all of them seem to be sent by me (thus component Composer). What's even more scary is that the nscpmsg-*.txt files are world-readable. (Which is a different bug than them being left behind, but I'm filing it with this anyways.) It may be important to know that a large number of sent mails fail to get copied into the Sent folder (but almost always get Sent), for a reason I haven't figured out yet, but that may be part of the cause why the files are left behind. I typically confirm in the upcoming the dialog that it's OK that they are not saved and no, I don't want to return to the Composer window. -rw------- 1 ben wheel 1558 Jun 21 12:26 nscopy-1.tmp -rw------- 1 ben wheel 1222 Jul 1 03:39 nscopy-10.tmp -rw------- 1 ben wheel 2724 Jul 1 10:34 nscopy-11.tmp -rw------- 1 ben wheel 1229 Jun 21 13:17 nscopy-2.tmp -rw------- 1 ben wheel 1165 Jun 21 14:00 nscopy-3.tmp -rw------- 1 ben wheel 971 Jun 28 11:03 nscopy-4.tmp -rw------- 1 ben wheel 2200 Jun 25 23:43 nscopy-5.tmp -rw------- 1 ben wheel 1071 Jun 29 12:45 nscopy-6.tmp -rw------- 1 ben wheel 2364 Jun 30 12:42 nscopy-7.tmp -rw------- 1 ben wheel 1077 Jul 1 03:28 nscopy-8.tmp -rw------- 1 ben wheel 1021 Jul 1 03:36 nscopy-9.tmp -rw------- 1 ben wheel 1335 Jun 21 00:13 nscopy.tmp -rw-r--r-- 1 ben wheel 1425 Jun 26 15:11 nscpmsg-1.txt -rw-r--r-- 1 ben wheel 1209 Jun 26 15:31 nscpmsg-2.txt -rw-r--r-- 1 ben wheel 1209 Jun 26 21:57 nscpmsg-3.txt -rw-r--r-- 1 ben wheel 1209 Jun 27 15:22 nscpmsg-4.txt -rw-r--r-- 1 ben wheel 1152 Jun 26 15:11 nscpmsg.txt -rw------- 1 ben wheel 1352 Jun 21 12:26 nsmail-1.eml -rw------- 1 ben wheel 1007 Jun 21 14:00 nsmail-1.html -rw------- 1 ben wheel 537 Jun 21 14:00 nsmail-1.tmp -rw------- 1 ben wheel 1192 Jul 1 03:39 nsmail-10.eml -rw------- 1 ben wheel 2608 Jul 1 10:34 nsmail-11.eml -rw------- 1 ben wheel 1199 Jun 21 13:17 nsmail-2.eml -rw------- 1 ben wheel 779 Jun 28 11:03 nsmail-2.html -rw------- 1 ben wheel 315 Jun 28 11:03 nsmail-2.tmp -rw------- 1 ben wheel 1135 Jun 21 14:00 nsmail-3.eml -rw------- 1 ben wheel 1662 Jun 25 23:43 nsmail-3.html -rw------- 1 ben wheel 1095 Jun 25 23:43 nsmail-3.tmp -rw------- 1 ben wheel 855 Jun 28 11:03 nsmail-4.eml -rw------- 1 ben wheel 887 Jun 29 12:45 nsmail-4.html -rw------- 1 ben wheel 391 Jun 29 12:45 nsmail-4.tmp -rw------- 1 ben wheel 2170 Jun 25 23:43 nsmail-5.eml -rw------- 1 ben wheel 2751 Jun 30 12:42 nsmail-5.html -rw------- 1 ben wheel 1622 Jun 30 12:42 nsmail-5.tmp -rw------- 1 ben wheel 955 Jun 29 12:45 nsmail-6.eml -rw------- 1 ben wheel 802 Jul 1 03:28 nsmail-6.html -rw------- 1 ben wheel 489 Jul 1 03:28 nsmail-6.tmp -rw------- 1 ben wheel 2248 Jun 30 12:42 nsmail-7.eml -rw------- 1 ben wheel 949 Jul 1 03:36 nsmail-7.html -rw------- 1 ben wheel 568 Jul 1 03:36 nsmail-7.tmp -rw------- 1 ben wheel 1047 Jul 1 03:28 nsmail-8.eml -rw------- 1 ben wheel 1052 Jul 1 03:39 nsmail-8.html -rw------- 1 ben wheel 673 Jul 1 03:39 nsmail-8.tmp -rw------- 1 ben wheel 991 Jul 1 03:36 nsmail-9.eml -rw------- 1 ben wheel 2512 Jul 1 10:34 nsmail-9.html -rw------- 1 ben wheel 1892 Jul 1 10:34 nsmail-9.tmp -rw------- 1 ben wheel 1129 Jun 21 00:13 nsmail.eml -rw------- 1 ben wheel 1098 Jun 21 13:17 nsmail.html -rw------- 1 ben wheel 597 Jun 21 13:17 nsmail.tmp
<http://lxr.mozilla.org/mozilla/search?string=nscpmsg> blames /mailnews/imap/src/nsImapMailFolder.cpp, line 3004 /mailnews/imap/src/nsImapOfflineSync.cpp, line 313
Dupe of bug 77810?
See also bug 58979.
QA Contact: composition
Product: Core → MailNews Core
Looks like this could be fixed by bug 235432. Please reopen if you still see it (new temp files left behind).
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
FWIW, right now I have (before the fix for bug 235432): $ ls /tmp/ns* /tmp/nscopy-10.tmp /tmp/nscopy-23.tmp /tmp/nscopy-7.tmp /tmp/nsemail-1.eml /tmp/nsemail-30.eml /tmp/nsemail-8.eml /tmp/nscopy-11.tmp /tmp/nscopy-24.tmp /tmp/nscopy-8.tmp /tmp/nsemail-1.html /tmp/nsemail-31.eml /tmp/nsemail-9.eml /tmp/nscopy-12.tmp /tmp/nscopy-25.tmp /tmp/nscopy-9.tmp /tmp/nsemail-20.eml /tmp/nsemail-32.eml /tmp/nsemail.eml /tmp/nscopy-13.tmp /tmp/nscopy-26.tmp /tmp/nscopy.tmp /tmp/nsemail-21.eml /tmp/nsemail-33.eml /tmp/nsemail.html /tmp/nscopy-14.tmp /tmp/nscopy-27.tmp /tmp/nsemail-10.eml /tmp/nsemail-22.eml /tmp/nsemail-3.eml /tmp/nsmail-1.tmp /tmp/nscopy-15.tmp /tmp/nscopy-28.tmp /tmp/nsemail-11.eml /tmp/nsemail-23.eml /tmp/nsemail-3.html /tmp/nsmail-2.tmp /tmp/nscopy-16.tmp /tmp/nscopy-29.tmp /tmp/nsemail-12.eml /tmp/nsemail-24.eml /tmp/nsemail-4.eml /tmp/nsmail-3.tmp /tmp/nscopy-17.tmp /tmp/nscopy-2.tmp /tmp/nsemail-13.eml /tmp/nsemail-25.eml /tmp/nsemail-4.html /tmp/nsmail-4.tmp /tmp/nscopy-18.tmp /tmp/nscopy-30.tmp /tmp/nsemail-14.eml /tmp/nsemail-26.eml /tmp/nsemail-5.eml /tmp/nsmail-5.tmp /tmp/nscopy-19.tmp /tmp/nscopy-31.tmp /tmp/nsemail-15.eml /tmp/nsemail-27.eml /tmp/nsemail-5.html /tmp/nsmail-6.tmp /tmp/nscopy-1.tmp /tmp/nscopy-3.tmp /tmp/nsemail-16.eml /tmp/nsemail-28.eml /tmp/nsemail-6.eml /tmp/nsmail-7.tmp /tmp/nscopy-20.tmp /tmp/nscopy-4.tmp /tmp/nsemail-17.eml /tmp/nsemail-29.eml /tmp/nsemail-6.html /tmp/nsmail.tmp /tmp/nscopy-21.tmp /tmp/nscopy-5.tmp /tmp/nsemail-18.eml /tmp/nsemail-2.eml /tmp/nsemail-7.eml /tmp/nscopy-22.tmp /tmp/nscopy-6.tmp /tmp/nsemail-19.eml /tmp/nsemail-2.html /tmp/nsemail-7.html
Bug 235432 fixed a case where we left behind nsmail-*.tmp files. It won't solve the nsemail-*.eml and nscopy-*.tmp files. REOPENing for those.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
:hiro, you fixed bug 235432, can you look at this one too? Looks like this could happen at copying messages, not composing.
Sure. If this bug is really happened on Mac OS X, I can not reproduce this issue, but I will try to look the code.
I could confirm this issue is reproducible on Linux. Steps to reproduce: 1. Open a compose window 2. Open another compose window 3. Save these message as draft 4. Close these compose windows 5. Exit Thunderbird I suppose the problem is that gComposeRecyclingListener in mail/components/compose/content/MsgComposeCommands.js is global, it should be created as an instance for each compose window.
OS: Mac OS X → All
Hardware: PowerPC → All
Thanks, Hiro. Note that step 5 shouldn't be necessary. If files are left behind after step 4, it's still a bug.
Hiro: Please note that there are 4 different file types above: * nsmail-*.tmp (fixed in bug 235432) * nsemail-*.eml * nsemail-*.html * nscopy-*.tmp One of them is probably what you say in comment 9, but there must be at least 1 or 2 more code places.
Attached patch Fix with a test (obsolete) — Splinter Review
Assignee: nobody → hiikezoe
Status: REOPENED → ASSIGNED
Attachment #611334 - Flags: review?(dbienvenu)
Comment on attachment 611334 [details] [diff] [review] Fix with a test Hiro, thx for the patch. You're clearing mMsgSend, not mDocShell, so the checkin comment seems wrong. Also, an explanation of why this patch fixes the bug would be helpful.
Comment on attachment 611334 [details] [diff] [review] Fix with a test patch works and test works/fails as expected. But I'd like to document why it works - is it breaking a cycle between nsMsgCompose and nsMsgComposeAndSend?
Attachment #611334 - Flags: review?(dbienvenu) → review+
Hiro, this is probably worth proposing for aurora once it has landed on the trunk - cleaning up these tmp file leaks is great.
Great, there is also one in bug 741027.
Comment on attachment 611334 [details] [diff] [review] Fix with a test +var expectedFiles; should be gExpectedFiles to make clear it's a global.
oops, one more question about the test - is do_register_cleanup() actually used?
Attached patch Revised patchSplinter Review
(In reply to David :Bienvenu from comment #14) > Comment on attachment 611334 [details] [diff] [review] > patch works and test works/fails as expected. But I'd like to document why > it works - is it breaking a cycle between nsMsgCompose and > nsMsgComposeAndSend? I actually do not investigate in further detail, but in case of comment #9 gMsgCompose in MsgComposeCommands.js is not nullified at exit of thunderbird. So I decided that mMsgSend is set to null (remove those temporary files) when compose window is closed for the safety.
Attachment #611334 - Attachment is obsolete: true
Attachment #611627 - Flags: review+
(In reply to David :Bienvenu from comment #18) > oops, one more question about the test - is do_register_cleanup() actually > used? Yes, when the test fails.
is this waiting for something before getting checked in?
No. I guess I forgot to set checkin-needed flag...
Keywords: checkin-needed
I'm thinking now we might want a more general approach to this, and add the ability for nsIMsgCompose clients to set the messageSend attribute, so that we can null it out after saving drafts, for example. I'm working on a patch to do so...
Status: ASSIGNED → RESOLVED
Closed: 13 years ago13 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 15.0
Sorry, i've got files of these types created with TB 15.0.1: nsemail-xx.eml nsmail-xx.tmp nscopy.tmp nsemail.html Creation dates vary from late august 2012 to today, october 17th, 2012. All of them are left in %TEMP%, where one doesn't want to manually take care for her/his privacy, as said before. If no questions arise, i might change status to reopened.
No longer blocks: 805626
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: