596950 - TBird 3.1.4 accumulates temporary graphics files

Status: NEW

(Thunderbird :: General, defect)

Description

[Steve Snyder]

This is seen with Thunderbird v3.1.4 (Release Candidate, Build #2) on WinXP/SP3.

When forwarding a message with graphics attached, TB creates a temporary file for each graphic.  A JPEG file is created in the form "nsmail.jpeg" and a PNG file is created as "nsmail.png".  Not only are these temporary graphics files not deleted once the message has been successfully sent, but they remain even after TB has been closed.

Further, the temporary files accumulate.  Given an existing temporary file named "nsmail.jpeg" forwarding another message with attached JPEG file results in the new temporary file "nsmail-1.jpeg" being created.  Apparently the number is bumped for each new temporary file created.

The temporary files are created in directory "C:\Documents and Settings\[username]\Local Settings\Temp\".  Given that graphics files can be quite large this behavior can result in a significant loss of disk space over time. Also, the temporary directory is normally hidden from the user on Windows, so the user can't simply erase those "temporary" graphics files.

Comment 1

[Ludovic Hirlimann [:Usul]]

Wayne , Aureliano , does this rings a bell ?

Comment 2

[Steve Snyder]

How to reproduce this bug:

1. Start TB with an empty temporary directory
2. Create a message, addressed to yourself, with 2 attachments: 1 JPEG file and 1 PNG file
3. Send message via SMTP, close TB, note temporary directory is still empty

4. Restart TB, go to the Sent folder and highlight the message just sent
5. Temporary graphics files are created when the Forward button is clicked
   (Files are erased if forwarding of message is aborted.)
6. Address the message being forwarded to yourself and Send it
7. After transmission successfully completes note that 2 files remain in the temporary directory: nsmail.jpeg and nsmail.png
8. Close TB and note that the 2 temporary files remain

9. Repeats steps 4 through 6 above.  Now there are 4 files in the temporary directory: nsmail.jpeg, nsmail.png, nsmail-1.jpeg, nsmail-1.png
10. Close TB and note that the 4 temporary graphics files remain.

The opening/closing of TB isn't necessary to reproduce the accumulation of temp files.  I added these steps to show that there isn't some sort of deferred erasure in place.  Those temp files are really not temporary after all.

Note #1: I have no add-ons installed, and do have Display Attachments Inline enabled.

Note #2: On WinXP one needs to enable "Folder Options>>View>>Show hidden files and folders" to see one's temporary directory.  This is disabled by default.

Comment 3

[Steve Snyder]

Nothing in the Error Console on the initial create and send of message.  However I get this informational (not Error) message:

2010-09-16 10:37:14	gloda.datastore	ERROR	got error in _asyncTrackerListener.handleError(): 19: PRIMARY KEY must be unique

in the course of doing a forward that leaves the temp files unerased.

Related?

Comment 4

[Ludovic Hirlimann [:Usul]]

(In reply to comment #3)
> 2010-09-16 10:37:14    gloda.datastore    ERROR    got error in
> _asyncTrackerListener.handleError(): 19: PRIMARY KEY must be unique

Andrew is that worth investigating ?

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

(In reply to comment #4)
> (In reply to comment #3)
> > 2010-09-16 10:37:14    gloda.datastore    ERROR    got error in
> > _asyncTrackerListener.handleError(): 19: PRIMARY KEY must be unique
> 
> Andrew is that worth investigating ?

I would be interested in knowing what is causing that to happen, but, strictly speaking, no it's not worth investigating at this time.  Because gloda dispatches all statements individually, such a problem should not cascade and likely has to do with the message attributes table in a way that is unlikely to affect any in-core gloda functionality usage.