TB is limited to 10000 temp files, and stops sending emails if nsmail-9999.tmp exists, and fails to open attachment by application if <attchment_filename>-9999.attachment_extention exists.

NEW
Unassigned

Status

()

8 years ago
6 years ago

People

(Reporter: demon, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [has pointers to code])

(Reporter)

Description

8 years ago
User Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110701 Iceweasel/3.5.16 (like Firefox/3.5.16)
Build ID: 20110701113851

Steps to reproduce:

Regarding all versions at least at Win XP.

Sending email fails if the limit of 10000 temp files is reached. I.e. there exists nsmail-9999.tmp in C:\Documents and Settings\User\Local Settings\Temp.

The error message is -- if email contains included files, then that the user has not enough rights to this files or if there are no files included then that the network preferences are wrong.


Actual results:

In fact TB is limited to 10000 temp files and cannot create a new temp file beyond nsmail-9999.tmp. TB fails without appropriate error message. It also does not remove its temp files, at it should.


Expected results:

TB shall remove its temp-files on its own and shall not be limited to 10000 temp-files.
(Reporter)

Comment 1

8 years ago
Workaround: remove all ns*.tmp in C:\Documents and Settings\User\Local Settings\Temp
(Reporter)

Comment 2

8 years ago
problem place #1: mozilla/xpcom/io/nsLocalFileCommon.cpp: line 172
mktemp shall be considered as replacement

Comment 3

8 years ago
I can confirm it for linux and tb 5.0

Steps to reproduce:
$ cd /tmp
$ touch nscopy.tmp; touch nsemail.eml
$ for i in `seq 1 9999`; do touch nscopy-$i.tmp; touch nsemail-$i.eml; done
Then try to write new message and save it as draft
duplicate of bug 389132?
(In reply to Wayne Mery (:wsmwk) from comment #4)
> duplicate of bug 389132?

Not really - this one would block.(In reply to Dimitri Sokolyuk from comment #2)

> problem place #1: mozilla/xpcom/io/nsLocalFileCommon.cpp: line 172
> mktemp shall be considered as replacement

Dimitri do you think you could come up with a patch to fix the issue ?
Component: General → XPCOM
Product: Thunderbird → Core
QA Contact: general → xpcom
Version: 5.0 → Trunk
(Reporter)

Comment 6

8 years ago
(In reply to Ludovic Hirlimann [:Usul] from comment #5)
> Dimitri do you think you could come up with a patch to fix the issue ?

Right now I'm a little out of time, but I'll see what I can do. However it's only a part of a problem. Much bigger problem is, that TB misses somewhere to destroy it's temporary files. I haven't find a location of this second problem right now.

Updated

8 years ago
Duplicate of this bug: 680303
(In reply to Wayne Mery (:wsmwk) from comment #7)
> NB bug 377621 is one potential source of these files. And it has a
> unfinished, uncommitted patch.

I don't think the nsmail.tmp files come from that, since that bug is about adding a new set of temporary files for drag-and-drop on GTK. Currently, temp files aren't created at all with drag-and-drop on GTK.
xref bug 389132, for ease of tracking & search.

As I wrote in bug 389132 comment #15, an easiest/simplist way to generate undeleted nsmail-NNNN.tmp is;
  Compose a mail and attach many mails, and "Send Later".
  Cancel mail sending(or Kill Tb), while creating many nsmail-NNNN.tmp.
As seen in bug 389132 comment #11, Tb tries to find free NNNN for nsmail-NNNN.tmp from nsmail.tmp/nsmail-1.tmp always. I was interested in "creation fail when NNNN==9999" case in that bug, but I didn't check it.

(In reply to Dimitri Sokolyuk from comment #0)
> It also does not remove its temp files, at it should.

(A) For "cancel of mail sending" case: Tb should remove temp files.
(B) For crash of Tb case:
    Application usually can not request remove if crash happens.
    So, user is usually responsible to remove garbages in /tmp or \Temp,
    or to clean up /tmp or \Temp periodically.
    It's ordinal design of OS used by PC.
    "Clean up by user" will be mandatory, even if system call like "mktemp"
    will be used, unless OS will be responsible to remove remained temp file
    after crash of an application.
Blocks: 389132
This bug is applicavle to temp file to open appachment by application.

For example, open attachment of filename=Voice.PDF by Adobe Reader on MS Win.
(1) Tb uses random name like "0QuEzw0F" (no quote) for temp file.
(2) Tb deletes C:\DOCUME~1\wada\LOCALS~1\Temp\0QuEzw0F.TXT (without ".part"). 
(3) Tb creates C:\DOCUME~1\wada\LOCALS~1\Temp\0QuEzw0F.TXT.part (with ".part"),
    and write attachment data to this file.
(4) Tb tries to rename C:\DOCUME~1\wada\LOCALS~1\Temp\0QuEzw0F.TXT.part
    to Voice.PDF.
    If Voice.PDF already exists, try to rename to Voice-1.PDF.
    If Voice-{N}.PDF already exists, try to rename to Voice-{N+1}.PDF,
    where N == 1 to 9998 (Max {N+1} == 9999).
(5-A) If rename to Voice.PDF or Voice-X.PDF (X == 1 to 9999) is successful,
    C:\DOCUME~1\wada\LOCALS~1\Temp\Voice-X.PDF is passed to application.
(5-B) If rename to Voice-9999.PDF fails, following dialog is shown, and "open attachment by application" fails.
> Downloading C:\DOCUME~1\wada\LOCALS~1\Temp\0QuEzw0F.TXT.part
>   ! C:\DOCUME~1\wada\LOCALS~1\Temp\0QuEzw0F.TXT.part could not be saved,
>        because an unknown error occurred.
>     Try saving to a different location.
>              [ OK ]

Problems in above.
(a) File name which is deleted at step (2) (without .part)  is different from file name which is used for data writing at step (3) (with .part).
(b) Because Tb tries Voice-1.PDF to Voice-9999.PDF serially, it usualy takes long.
(c) Error message at step (5-B) is incorrect, because writing data to 0QuEzw0F.TXT.part itself is successful. Error message should indicate file name of Voice-9999.PDF in the dialog.

Note-1:
If "Cancel" is requested at "Open Dialog", temp file of C:\DOCUME~1\wada\LOCALS~1\Temp\0QuEzw0F.TXT.part is normally deleted by Tb 8. So, garbage is not produced by "Cancel" in this case. 

Note-2:
If "open attachment by application" is requested multiple times for same attachment at same time by user, Tb writes data to differnt {random_string}.PDF, and renames to different Voice-NNNN.PDF.

Note-3:
If rename to Voice-A.PDF, Voice-B.PDF, Voice-C.PDF, ..., is successful, these temp files are used by external application. So, these files are not deleted by Tb while Tb is running.
When browser.download.manager.retention=1(Tb's default=1), these temp files are deleted upon termination of Tb, if and only if termination of Tb is successful and delete request by Tb is successful.
i.e.
If system crash, power failure, Tb's hung/freeze etc. occurs before deletion of temp files by Tb, or if temp file is still opened by application when Tb tries to delete the temp file upon termiation of Tb, temp file remains in Temp directory of system.
OS usually never deletes such remaining temp files automatically. So, user needs to delete such garbage files by himself.  It's OS's design.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Summary: TB is limited to 10000 temp files and stops sending emails if nsmail-9999.tmp exists. → TB is limited to 10000 temp files, and stops sending emails if nsmail-9999.tmp exists, and fails to open attachment by application if <attchment_filename>-9999.attachment_extention exists.
Duplicate of this bug: 671440
Duplicate of this bug: 781478

Comment 15

6 years ago
Impressive that this is still broken almost two years after the bug was filed.

Updated

6 years ago
Duplicate of this bug: 812949
Looks like this is a limitation of createUnique:
http://hg.mozilla.org/mozilla-central/annotate/81dd97739fa1/xpcom/io/nsLocalFileCommon.cpp#l138
Whiteboard: [has pointers to code]

Comment 18

6 years ago
Jonathan, do you still have 9999 nsmail temp files existing?
I think recently there were some fixes to not leave stray temp files around.

Does anybody think we should add some code to TB to delete all stray temp files belonging to TB on startup (e.g. nsmail-*.tmp, but there still may be a clash if Seamonkey is running alongside) ?
(In reply to :aceman from comment #18)
> Jonathan, do you still have 9999 nsmail temp files existing?
> I think recently there were some fixes to not leave stray temp files around.
> 
> Does anybody think we should add some code to TB to delete all stray temp
> files belonging to TB on startup (e.g. nsmail-*.tmp, but there still may be
> a clash if Seamonkey is running alongside) ?

Something needs to be done bug I'm ambivalent about a wallpaper solution that hides symptoms of real problems/incorrect code.  In other words, I'm sure there are cases where we can outright fix problems.  https://bugzilla.mozilla.org/buglist.cgi?f1=OP&o3=anywordssubstr&list_id=7707974&short_desc=temp%20tmp%20temporary%20nseml%20nstmp%20nstemp&resolution=---&resolution=FIXED&resolution=EXPIRED&classification=Client%20Software&classification=Components&o2=nowordssubstr&f4=CP&query_format=advanced&j1=OR&f3=keywords&f2=short_desc&short_desc_type=anywords&v2=templat%20biff%20contact%20cert&product=MailNews%20Core&product=Thunderbird lays out the history and what's left to fix.

bug 553165 is the wallpaper idea.
You need to log in before you can comment on or make changes to this bug.