This is really wierd, for like more than a week - I've had this folder, 'nstmp' that reappears under my POP3 account with one message within it. When I delete the folder, it disappears but may sometime later reappear. The latest time I saw this was just now (build 20010629).
I have been reading the bugzilla FAQs and information but haven't found a better way to submit supporting occurances of bugs so I am emailing you directly. Related to bug # 88515: I have the 'nstmp' folder appearing while running Mozilla (version(s) .9.1 and .9.2) under Windows 2000 Professional. I believe this is related to bug # 81578: I cannot delete a large selection of email messages either. Situation #1: I also have 4 'ghost' emails in my inbox. The inbox count says '1' yet there are 4 emails in the inbox. One of the 'ghost' emails cannot be deleted/moved. This is just after moving a large amount of emails into a folder (724 emails to be exact). I right click on the inbox, expecting to try to compact it. The inbox refreshes and shows the 724 emails I just moved, a nstmp folder, and pops up a error message 'Alert; Unknow error 80520012' The other thing to note is that I am using multiple pop accounts. If you think I should submit a seperate bug (it is under Win2000 vs. Win95 as submitted) please let me know. Happy Coding, Norman Robinson
This happens for me on Win2kProf-SP2, build 2001112803. The folder contained copies of all the mails I had in my inbox.
A "nstmp" folder was created in my Mozilla POP mail folder today after compacting my folders. I'm using Mozilla 2002040708 on Win32. Could this be a duplicate of bug 70322?
Are you sure that it happened with the latest build and not with netscape 6.2.2 ? I don't remember netscape 6.2.2 having this bug though.
I have the same extremely annoying problem with build 20020407. After I have deleted one or more messages in a folder and compacted the folders, Mozilla _always_ creates an nstmp file in that directory. Even though the deleted messages should have been removed from the file containing the folder the file has not changed at all and was not compacted! I can find the content of the compacted folder in nstmp (which of course get overwritten if more than one folder gets compacted). It seems that sometimes Mozilla also regularly fails to finish compacting folders for whatever odd reason (at least according to the status bar). I think this bug has to be fixed for Mozilla 1.0 !
I have downgraded to build 20020405-15 (Windows 2000) and the bug is gone. The only checkin between 20020405-15 and 20020407 that could have caused this seems to be the fix for bug 122361.
Having kinda randomly this empty folder since 3 or 4 builds (downloading each daily one). Build 2002040903 - WinXP
I first ran into this using 2002041003 on W2K. After compacting my pop-inbox the nstmp-folder was present at the next startup, nstmp was the compacted 30kB version of my 300 kB inbox, both were readable. This may also be related to the more severe dataloss problem Edward Buck reported on n.p.m.mail-news on 09.04.2002. Adding keywords since this was confirmed so often the last few days.
yes, this was because we were leaving stream open to the local folders - berekeley box. See bug 136626 for the fix. This has been fixed on trunk and should be okay in today's build. Please try again.
I have this happening with the latest build on Win2k (2002060904). Steps : - I launch "compact folders" (folders are small, shouldn't be long), - I wait quite a long time - I quit and relaunch, a "nstmp" folder appeared This is not related to disk space, quotas ... it seems that the "compact folder" thing starts and never stops ...
I've just seen a condition where mail folder compaction threw an error message indicating that the folder was in use and could not be compacted. After seeing this message, the Inbox thread pane was empty. Looking in the profile mail folder, I saw that the Inbox mail file was missing. Inbox.msf was present, as well as a new file named nstmp. The nstmp file appeared to be a temporary copy of the Inbox file used by the compaction process. I deleted Inbox.msf, renamed nstmp to Inbox and restarted Mozilla. Mozilla rebuilt Inbox.msf and the Inbox was restored. Perhaps a separate bug should be filed for the compaction contention problem? Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020818
Navin, is this compact contention bug still on the 1.1 branch? Or, put another way, has it been fixed on the trunk since the 1.1 branch? I can't tell if the reporter was using auto-compact or manual compact.
Ron, was this auto-compact or manual compact ?
*** Bug 198308 has been marked as a duplicate of this bug. ***
Please forgive my ignorance, as there's a lot of this I don't understand, but I have been dealing with this problem (or one very much like it) for over a week now. I'm using Netscape 7.02 and Netscape Mail with Win98. I've noticed several different symptoms, and I'm not sure all of them are related, but they seem to be. I receive a fairly large quantity of mail (approx. 250 messages/day) 90% of which is SPAM. One message I've been getting a lot of lately shows no subject and no sender, and is dated sometime in 1969. These messages remain unopened and unread when clicked on, and seem to affect the display of other unread messages in my Inbox. Once the 1969 message has been clicked on, the next few messages I look at have bodies and headers that don't match (i.e. what's being displayed is a 'ghost' visual). The 1969 messages can be moved to the trash using the delete button, but the number of messages then shown in the trash is not always accurate. The folder window may show 4 unread messages in the trash folder, but only 1 or 2 can be seen when the folder is opened. Additionally, the trash folder can only be emptied of these unread messages when it is open. At about the same time these phenomena started, I began noticing that the folder compacting function works differently now than it used to. Aside from continually creating nstmp folders (intermittently and unpredictably) that duplicate the 280-odd messages in my Inbox, the Inbox folder itself seems to go through a rebuilding process. When the compact command is first given, the 280 messages disappear, and then the folder is rapidly filled up with them again (takes about 5 seconds). I don't know if any of this information is helpful, and I apologize if this message is inappropriate. I found this site while searching for answers. I will continue to search, but I would be very gratedul for any help or advice.
confirming existence of bug in mozilla 1.4 release / win32.
I've not seen this bug for a long time. Currently using 1.5 release / win32.
I'm currently seeingthis bug in Thunderbird 0.4 on Windows 98. On account "pop" I had the standard folders (Inbox, etc), and I created a "bugmail" folder for bugmail. In addition, I have other accounts. I created a filter under pop for bugmail. I forgot to enable the filter, and it wasn't working. After several system hangs and crashes the bugmail folder became corrupt. It stopped working. I couldn't move messages into it. I couldn't delete the folder. I couldn't move the folder elsewhere. Eventually, after more crashes, folder "nstmp" also appeared. Finally, I deleted the subdirectory "bugmail" in the Thunderbird profile directory. At this moment, folder nstmp has 53 unread messages. Inbox has 67 unread messages. All of the messages in nstmp appear to be in the Inbox. New messages are going to Inbox, not nstmp. I have compacted the folders, including Inbox, several times. Would anyone like more information? It appears that the compact folder function screws up somehow. Perhaps if during a compact folder operation that takes more than a few seconds a system crash appears, the nstmp folder created by the compact folder operation is not subsequently, automatically deleted, as it should be. See also bug 163851.
nstmp is the temporary folder used to compact a folder ( we copy non-deleted messages to nstmp, and then if that succeeds, we copy nstmp back over the original folder, and delete nstmp). If the compact process is aborted due to a crash, or to the user shutting down while compaction is going on, it will get left around, and not cleaned up. In theory, we could just delete it on the next startup, but there's always the chance that it contains data the user wants.
*** Bug 282716 has been marked as a duplicate of this bug. ***
I've just started seeing the nstmp-x folders appear. I've been using Mozilla mail for years and NEVER seen this before. What's changed? I just installed Google desktop (it indexes my mail for me). There's some kind of interaction going on.
I just wanted to add my observation that in bug #282716 which I filed (and was later folded into this pre-existing bug), I observed a similar problem to Colin's in comment #23. I was using Mozilla mail for a year without any trouble from these nstmp-x folders, I only started seeing them after installing x-1 Search (a mail/file quick search indexer) which seems to be interacting with mozilla mail. The folders don't seem to appear on a regular basis, however I'm pretty sure there's some interaction between indexing with x-1 and compacting in mozilla mail. Just for completeness I'll be mentioning this bug thread to x-1's developers and making a bug report there.
I'm now seeing this in 1.0.2.
I'm using TB 1.0 and I can confirm it. I have about 5 nstmp folders, should I delete them?
I have these folders, too. Maybe it has something to do with the Google-Desktop-Search that I use now.
yes, Google Desktop Search is having some sort of bad interaction with the mailnews backend code. We think it has to do with folder compaction - do these tmp folders appear after either manual or automatic folder compaction is run?
I have deleted these nstmp-Folders and launch TB again and everthing is ok. Now I delete some mail und use automatic folder compaction, but no nstmp folder appears. Then I delete some other mail and use manual folder compaction but there are also no new nstmp folders. I restart TB nothing. Google Desktop Search is still running in the background :-( Maybe I must wait until Google index my mails again.
I would like to second Colin's assertion that it appears to be an interaction with Google Desktop Search (GDS). I have just started to see this problem literally the day after installing GDS, which would have been the first opportunity for me to see it given the descriptions of how these show up. I have previously been using thunderbird 1.0.2 on Windows 200 Pro for 2 months (well, 5 days short) and have been using various versions of thunderbird for over a year without previously seeing this issue. I'll be removing GDS--my mail is much more important.
I forgot to mention; this is occuring with automatic folder compacting.
if X-1 Search is causing this problem, I bet it's locking the mailbox files at the OS level, and reading them as text files. I doubt it's using the mailnews api's. So if it's having the same issue as GDS, perhaps the cause is the same. The folder compaction code tries to clean up temp files in case of error, but something must be going wrong...
Just to confirm that this bug looks like it is the result of the interaction between Google Desktop and compacting folders in Thunderbird. I manually compact folders regularly and since installing GDS I now notice that nstmp-* folders appear. A workaround might be to pause GDS indexing before manually compacting folders. Am using Thunderbird version 1.0 (20041206) on Windows XP.
@ comment 33: Try with the latest version of TB? (1.0.2)
(In reply to comment #34) > Try with the latest version of TB? (1.0.2) It happens with 1.0.2; see comment #30.
Just a note to verify that this is still an issue. Got the nstmp folder using Thunderbird 1.0+ (20050601). Also, in response to comment 30, comment 32 and comment 33: I do not have google desktop search installed, so I doubt it has much to do with it. Perhaps GDS aggravates the problem, but it is not the root of the problem.
Created attachment 187909 [details] [diff] [review] proposed fix the main fix is in the folder compaction code - pay attention to whether the deletes and renames succeed (we can only tell if the delete fails by checking if the file still exists after deletion). If any of the deletes or renames fail, try to clean up the temp files as best we can. There's no guarantee that whatever's causing the locks won't still be a problem, but with my testing, this patch does improve things. The nsMsgDatabase part of the patch covers a related issue - when a third party extension iterates over the messages in a db, like GDS does, the enumerator holds onto a db. I've changed the enumerator to listen to change notifications so that if the db gets forced close, which compaction does, the enumerator releases its ref to the db. I think this could help with some problems.
fix checked in.
Don't know if this is still of any help, but since the following situation isn't mentioned anywhere in this bug report, i'd like to report that i get this error regularly in 1.0.6 (20050716) and only in the following situation: After deleting messages and clicking File -> Empty Trash, the trash folder often "disappears" (only in the UI). If i shut down and restart TB, the trash folder reappears, and then compacting works correctly. But if i compact before restarting, i.e. with an "invisible" trash folder, i get a nstmp folder (and a new one for each compacting attempt until i restart TB and the trash folder reappears).
I have begun receiving the nstmp folder mentioned in the discussion above in the last few days. I have read the details of the proposed fix, but have no earthly idea what it is talking about. I can operate my PC quite well, but I am not at all technically proficient in coding or "fixes." Is there something relatively simple I can do to eliminate this problem, or could someone walk me through the steps that are necessary, please? Thanks, Caleb Halstead
Also seeing this with 1.5.
(In reply to comment #41) > Also seeing this with 1.5. > Yes, me too -- this is really annoying; there is at the moment nstmp, nstmp-1 ... nstmp-14 folders in my inbox! It can take an hour to delete them as Firefox responds so slow, and then they are just there tomorrow again. This is sad; I need my desktop search, but I can use another email programme. - Frans
>Yes, me too Me too. Windows XP sp2. I have a very large inbox on a POP3 mailserver (exchange, I assume) and since turning on an option like "Compact folders at exit" (or something like it, I cannot now find the setting), I have nstmp, nstmp-1, ... nstmp-15. When I delete them (right click > "delete folder") the folder seems to go into the Trash but when I restart it is back (in fact, if I haven't emptied the Trash, then I cannot delete it again because "there is an item with the same name..."). What finally seems to have worked to remove these is to physically delete the nstmp*, nstmp*.nsf and nstmp*.sbd files and folders from the Mail directory where TB stores the files. I don't know what's happening but I would not be surprised if I were shutting TB down during a compact process because there is so little indication of what it's doing. My TB throbber seems to throb non-stop and the status bar indicator is so unreliable. I'd like an option for a modal dialog to appear with the progress updated in bytes each second so I can see what's happening. As a stop-gap, what I do now is I open the Mail directory and watch nstmp grow and then be deleted. Only then to I shut down TB. But this is extremely cludgy.
Is there a patch or has there been an update to fix this bug? I am working with version 1.0.6 (20050716). I get multiple versions of the "nstmp" folders. They seem to occur both when moving messages from one folder to another and when deleting multiple/duplicate messages. I cannot delete them because they seem to be self-replicating. Every time I delete an nstmp folder, empty trash, and compact folders--a new nstmp folder appears.
Im using the latest build of Thunderbird 18.104.22.168 (20080421) and nstmp appeared in one of my users. Isn't solved? Do you know why it appeared? Thunderbird loads a profile from a shared folder in the network.
I got this in the last month as well. DEFINITELY not solved in 2.x version!
I'm seeing this annoying nstmp folder as well - I notice its marked "RESOLVED FIXED" but clearly isn't,
I also have a huge number of nstmp files : 126 nstmp* files in my Thunderbird profile
struck for the first time with this bug: a nstmp folder in my local folders appeared with thunderbird Version 22.214.171.124 (20090605); maybe you should mark this bug as WONTFIX, not RESOLVED FIXED.
Any chance of bringing this fix to the branch if we won't get a trunk release in the next month?
Got the same issue here, to an amount of 50gb !! I have remove my nstmp files et lauch again, with success. Can't say if it come back, because I done it, about 2h. icedove : v3.1.11 debian sid kernel : 2.6.39-2