Open
Bug 58979
Opened 24 years ago
Updated 1 year ago
store all compose temp files in directory under /tmp, and remove that directory on quit
Categories
(MailNews Core :: Composition, defect)
MailNews Core
Composition
Tracking
(Not tracked)
NEW
People
(Reporter: sspitzer, Unassigned)
References
Details
(Keywords: privacy)
instead of dumping the temp files to /tmp/ns*.eml, /tmp/ns*.html, etc
we should be putting them in a directory under tmp.
then on shutdown, we can remove that entire directory.
see bug #58580.
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Comment 1•24 years ago
|
||
CC'ing self and adding privacy keyword. Nominating for mozilla 0.6
Creating a separate directory is not necessary, but whatever it takes to wipe
out these files as soon as the message is sent.
Keywords: mozilla0.6,
privacy
Comment 2•24 years ago
|
||
I should add that clearing the files on shutdown is not very satisfactory since
crashes (which we all know are not too uncommon) will leave them behind. If you
compose a mail message and send it immediately, Mozilla does the right thing. Is
there not some routine that cleans up after a mail composition? Could it be used
for news postings and mail sent after being saved as a draft?
Reporter | ||
Comment 3•24 years ago
|
||
yes, we intend to clean up upon post or sending of drafts.
last time I talk to rhp, he said that we are probably leaking one of the send
objects when we post or send drafts, which is why we are aren't removing the
temp files.
having the separate directory isn't necessary, but I'd prefer it to dump files
right into /tmp
it also makes removing all temp files on shutdown (or startup, to fix the crash
case) simpler, since all we have to do is remove the correct folder under tmp.
jerry, do you have any time to help investigate the leak?
Comment 4•24 years ago
|
||
Not terrible loads of time, but I have some.
Updated•24 years ago
|
Keywords: mozilla0.6
Comment 9•23 years ago
|
||
We have fixed most of the leak and added a list of temp file to be removed into
nsIMsgCompFields. Temp files are removed when the compose fileds goes away.
I don't know if we still should do that! maybe in the future...
Status: NEW → ASSIGNED
Comment 10•23 years ago
|
||
Mass removing self from CC list.
Comment 11•23 years ago
|
||
Now I feel sumb because I have to add back. Sorry for the spam.
Comment 12•23 years ago
|
||
NO downloads should be temporarily stored in /tmp; The /tmp directory is often
on a minimal root partition and fills up rather easily. The temporary files
should be stored where the user is directing the download, otherwise downloads
can and will fail. See bug #69938
Updated•20 years ago
|
Product: MailNews → Core
Comment 13•17 years ago
|
||
we really shouldn't be leaving files to fill up people's disks, not to mention the privacy issue. bumping to major.
perhaps temp directory for mapi should also go there - currently is temp\moz_mapi\
Assignee: ducarroz → nobody
Severity: normal → major
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: pmock → composition
Hardware: PC → All
Target Milestone: Future → ---
Assignee | ||
Updated•16 years ago
|
Product: Core → MailNews Core
Comment 14•13 years ago
|
||
(for searchability) /tmp/ns* includes nsemail and nsmail
Comment 15•13 years ago
|
||
Why can't they be placed inside the profile directory?
Comment 16•13 years ago
|
||
The leaving of files behind should be fixed by bug 235432.
So this bug is about changing when/where to store the files temporarily.
Depends on: 235432
Comment 17•13 years ago
|
||
> The leaving of files behind should be fixed by bug 235432.
No, that fixes only one case, there is other code where we leave files behind.
Comment 18•13 years ago
|
||
OK, then that leaving files behind is covered by other bugs, like bug 299655.
I just wanted to point it out again (as the comments were straying from the original description), that this is NOT a dupe of 235432 or 299655 as this has a good idea of changing the way/place of saving the files.
Comment 19•13 years ago
|
||
> NOT a dup ... this has a good idea of changing the way/place of saving the files.
Agreed.
You need to log in
before you can comment on or make changes to this bug.
Description
•