979893 - Mail-save operation is long (75s and longer) deleting nsemail.eml from Windows temp directory which is in non-standard location and therefore gets indexed

Status: NEW

(Thunderbird :: Message Compose Window, defect)

Description

[Rudolf]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; .NET4.0E; .NET4.0C; Media Center PC 6.0; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729; rv:11.0) like Gecko

Steps to reproduce:

Create eMail with text and 2 large attachments (2MB or more).
Thunderbird stops responding for a longer time, as described in "Actual Results" below.

Environment: I'm using Windows with a Thunderbird profile-directory of 456MB in size.
A few weeks ago I've removed about 6000 outdated mails and 3.1 GB(!) in size. The behavior did not obviously change with the reduction of mail-count and size. The problem occured before and after this change, also with Thunderbird versions earlier than 24.3.


Actual results:

Thunderbird hangs in any of the following conditions:
* autosave (while typing text)
* saving draft
* sending the mail
The program is not responsible for a longer duration (can be 75 seconds and longer).

Other conditions while unresponsive:
* About 100MB memory consumption (normal)
* 0% CPU Load (waiting for something, maybe file-operations?)

Comment 1

[Wayne Mery (:wsmwk)]

what is 
- size of drafts folder?
- size of trash folder?

which antivirus software do you run?
is it set to exclude the thunderbird profile?

Comment 2

[Rudolf]

Size of "Drafts" folder is: 39 KB
Size of "Trash" folder is:  3 KB

Antivirus: Avast 2014 Free Antivirus
Thunderbird profile is excluded. Even if the scanner is (temporary) completely disabled the problem persists.

Note: I'm using 5 accounts with additional aliases (identifications) mapped to a single "Local folders" folder. I don't expect this to affect the behavior, but who knows?

Comment 3

[Wayne Mery (:wsmwk)]

all pop accounts?

Start *Windows'* safe mode with networking enabled
- win8 http://windows.microsoft.com/en-US/windows-8/windows-startup-settings-including-safe-mode

Still In Windows safe mode, start thunderbird in safe mode
- http://support.mozillamessaging.com/en-US/kb/safe-mode

Does problem go away?

- If no, then problem is either: bug in Thunderbird, in your Thunderbird  profile, your mail provider. Please post into topic the contents of Help | Troubleshooting | copy text to clipboard

- If yes, (still in Windows safe mode) ... start Thunderbird normally
    -- If problem is still gone, then cause is a program loaded during windows startup.  Possibilities include: antivirus SW, virus/malware, background downloads such as program updates
    -- If problem is NOT gone, then cause is likely a Thunderbird addon - eliminate them by disabling each one at a time in Tools | addons | extensions and restarting

- If results are unclear ... possibilities include temporary conditions such as contention from other running programs, downloads related to windows update, ...

Please  let us know your findings.

Comment 4

[Rudolf]

Very good, explanation. Thanks! With this I've found the following:

* In Windows safe-mode everything is working as expected. Thunderbird is fast in thunderbird-safemode and normal.

* In Windows normal mode the problem may not always occur (for tests now I've used 1 mail with 5 PDF attachments that have 9.7MB in total). After complete reboot I could save the draft 2 times without problems. Afterwards every save-attempt takes a long time. No matter if:
- I logoff and logon again
- I restart thunderbird in safe-mode
- Plugins and Addons are disabled

I was software-developer and invested a bit more efforts to figure out what hangs. In the debugger I've seen the following. When saving the draft-mail Thunderbird deletes two files in the TEMP-folder with DeleteFile():
-> nscopy.tmp (fast, even if very huge)
-> nsemail.eml (CAUSES the noticed DELAY)

My suggestion was that the .eml extension uses a shell-handler that takes more time. Even if DeleteFile() bypasses the ShellHandlers I've tried to disable them - without success. I have no idea what causes this delay. My system uses only a few needed programs only...

Comment 5

[Wayne Mery (:wsmwk)]

how many files in %temp%?

If still bad when temp size is near zero, then Avast may be part of the equation.
But you don't really want to set avast to ignore %temp% directory.

Comment 6

[Rudolf]

TEMP-folder is almost empty (no old artefacts, only 3-5 files that are currently in use).

I've temporarily disabled Avast for 10 minutes without effect. Even if Avast does no longer report "nsemail.eml" being realtime-scanned the delay persists. Maybe the Avast-FilterDriver still scans the file, but does not report issues if infected (still checking).

Comment 7

[Rudolf]

I've tried to disable the Avast-FilterDriver's (aswMonFlt and aswStm). No change.
In meantime I'm sure that one of the installed FilterDrivers (AvastAntivirus, AcronisTrueimage, ...) causes this problem. This is also confirmed by the WindowsExplorer, which also has a long pause when attempting to delete this file (but performs this I/O asynchronously).

So Thunderbird cannot fix that much, except keeping the UserInterface a bit more responsive.

Comment 8

[Rudolf]

Still have not found the cause, but some more results.
The problem occurs with "nsemail.eml":
* when deleting the file
* when renaming the file (e.g. to "nsemail.eml.dat", "nsemail.dat", "nsemail.doc" or "nsemail.pdf")
* when performing the operations on command-prompt (where shell-handlers are excluded)

It does NOT occur:
* when deleting the renamed file
* when renaming the file back to "nsemail.eml"

Conculsion: the behavior is specific to the "*.eml" file extension (in combination with the huge file-size).

Comment 9

[Rudolf]

FOUND (thank you very much for the initial hints)!

The problem is specific to my machine (C: = SSD, D: = HDD), but may apply to some other users as well. Therefore a more detailed explanation can be found here:

1) Windows and "User" directories are on C: (SSD)
2) Because the SSD has a limited storage-capacity and to avoid unnecessary I/O most user-data (including TEMP-folder) are located on D:
3) This is, so far, ok and works perfectly, but: the TEMP-folder on D: is (was) not excluded from the Windows Indexing service. This should be done in the ControlPanel "Indexing options"

What happened:

1) When saving the mail "nsemail.eml" is created in the temp-folder
2) The indexing-service recognized a new file of known type (.EML) to be indexed and scanned the file immediately, taking the recognized long time
3) Meanwhile thunderbird attempted to delete the temporary file "nsemail.eml"

This resulted in the following race-condition:

* The file "nsemail.eml" could not be deleted while scanned by SearchProtocolHost.exe, therefore the delete-operation was blocked until the scan has been finished. After this the file "nsemail.eml" was deleted as expected.

SOLUTION FOR THIS CASE: the TEMP-folder has to be excluded from the indexing-service. This is because ".eml" is a recognized filetype that is automatically processed by the indexing-service, even is created for a very short-time only.

Comment 10

[Wayne Mery (:wsmwk)]

windows indexing is item 9 at https://wiki.mozilla.org/Thunderbird:Testing:Memory_Usage_Problems

perhaps the extension name(s) used in the temp folder should be changed??

Comment 11

[Wayne Mery (:wsmwk)]

correction - item 9 is about "windows integrated search" option being enabled in *Thunderbird*, not about Windows indexing being enabled

Comment 12

[Rudolf]

"MS-Windows Integrated Search" is disabled in Thunderbird.
But the Windows Indexing Service has indexing for ".EML" files (properties and contents) enabled. It uses the Windows "MIME-Filter" (mimefilt.dll, which is provided by Microsoft).

Extension name change (.dat, .tmp, ...) could be helpful. On the other hand virus-scanners may skip files of such types.

Comment 13

[Wayne Mery (:wsmwk)]

(In reply to Rudolf from comment #9)
> SOLUTION FOR THIS CASE: the TEMP-folder has to be excluded from the
> indexing-service. This is because ".eml" is a recognized filetype that is
> automatically processed by the indexing-service, even is created for a very
> short-time only.

I disable the Windows Search Service on all my machines - I don't use search often enough that it's worth having the windows overhead 100% of the time *especially* on laptops. And I dare say the majority of users probably fit either usecase. 

However, indexing is default and so essentially all of our Windows users are affected performance-wise in at least little ways, if not big.

Comment 14

[Wayne Mery (:wsmwk)]

perhaps import process is also affected https://getsatisfaction.com/mozilla_messaging/topics/is_nsemail_eml_harmful_or_necessary - what would be a huge performance drain

there is also bug 769346, where large messages are most affected

Comment 15

[:aceman]

So this could probably be done. Is anybody against it?
Do we want to name the file as .eml.tmp or something?

Comment 16

[:aceman]

But Windows indexing should probably skip TEMP by default...

Comment 17

[Wayne Mery (:wsmwk)]

(In reply to :aceman from comment #16)
> But Windows indexing should probably skip TEMP by default...

Indeed it probably should skip - the thought had crossed my mind.
But imagine, what are the odds of Microsoft making that happen, in our lifetime? :)

Comment 18

[Rudolf]

Windows indexing skips TEMP by default.
This problem occured because I've changed the standard-configuration,
but forgot to adjust this minor setting in the indexing-options :-(

Comment 19

[Wayne Mery (:wsmwk)]

(In reply to Rudolf from comment #18)
> Windows indexing skips TEMP by default.
> This problem occured because I've changed the standard-configuration,
> but forgot to adjust this minor setting in the indexing-options :-(

bummer.  yeah, I just checked my win7 system and, based on spot check, all of appdata\ is not indexed.

But I wonder whether not-indexing is true if the user has changed %temp% to point to some other directory?

Comment 20

[Rudolf]

You're right: the complete "AppData" is excluded (with nested folder "AppData\Local\TEMP").
So it is not indexed.

When moving the TEMP-folder it's usually outside of this hierarchy and will be
most likely indexed by default (until explicitly excluded in the "Indexing options").
This is also what happend in my case :-(

Comment 21

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 22

[Rudolf]

New severity: S3
(how can I set it?)