Closed Bug 88515 (nstmp) Opened 23 years ago Closed 19 years ago

Mysterious 'nstmp' folder reappearing

Categories

(MailNews Core :: Backend, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: hwaara, Assigned: Bienvenu)

References

Details

(Keywords: regression)

Attachments

(1 file)

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).
This may be related to bug 70322 and bug 66795.
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.
Component: Networking - POP → Mail Back End
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. ***
mass re-assign.
Assignee: naving → sspitzer
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.
Keywords: mozilla1.0
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.
Product: MailNews → Core
*** 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.
Attached patch proposed fixSplinter Review
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.
Assignee: sspitzer → bienvenu
Status: NEW → ASSIGNED
Attachment #187909 - Flags: superreview?(mscott)
Attachment #187909 - Flags: superreview?(mscott) → superreview+
Attachment #187909 - Flags: approval-aviary1.1a2?
Attachment #187909 - Flags: approval-aviary1.1a2? → approval-aviary1.1a2+
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
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 2.0.0.14 (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!
Product: Core → MailNews Core
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 2.0.0.22 (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
Guillaume, please see bug 498814 and bug 673703
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: