Closed Bug 66795 Opened 24 years ago Closed 23 years ago

POP Mail folder "nstmp" appeared

Categories

(MailNews Core :: Backend, defect, P2)

x86
Windows 2000
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.2

People

(Reporter: dev+mozilla, Assigned: Bienvenu)

References

Details

(Keywords: platform-parity, Whiteboard: [nsbeta1+])

Attachments

(3 files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20010125
BuildID:    2001012504

After starting Mozilla, I found a mail subfolder "nstmp" in one of my folders.
It is a copy of another subfolder in that folder.

Reproducible: Didn't try

Actual Results:  A new folder "nstmp" appeared.

Expected Results:  No folder shall appear unasked in MailNews. =.->
not a mail database issue, a mailbackend issue, reassigning to putterman for truage
Assignee: bienvenu → putterman
Component: Mail Database → Mail Back End
QA Contact: esther → sheelar
reporter, imap or pop?
pop
Adding POP on the summary to specify this problem on POP...
Summary: Mail folder "nstmp" appeared → POP Mail folder "nstmp" appeared
I am not seeing this. Reporter try downloading the latest nightly at
http://www.mozillazine.org/build_comments/ and creating a new profile, see if
that fixes the problem.
See bug 66817 for a way to reproduce this (sometimes).
Mozilla creates an nstmp temp file when compacting a large (several megabytes)
folder, then renames it to the name of the folder being compacted. This appears
to be by design, though I don't know. The nstmp file reported probably appeared
when a compact folder operation failed midway through.
confirming this bug on win98 buildid 2001021909. 
Delete message in pop inbox
Compact inbox folder
Delete messages again 
compact inbox
close the app and open mail again
you will see nsmtp created in the folder pane
I have noticed that the nsmtp folder size gets as big as the inbox folder and
upon delete messages further appears to move to nsmtp folder instead of trash
folder.

Also adding keyword as nsbeta1 so that this bug can be fixed. 
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: nsbeta1
change severity and os to all
Severity: minor → major
OS: Windows 2000 → All
marking nsbeta1+ and moving to mozilla0.9

reassigning to naving.
Assignee: putterman → naving
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.9
Priority: -- → P2
This bug will get fixed when #69862 lands
Depends on: 69862
fixed as a result of fixing #69862
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
#69862 is backed out.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
fix checked in. 
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
No longer depends on: 69862
Resolution: --- → FIXED
verified this bug as follows:
delete lots of messages in pop inbox folder
compact inbox folder
close and reopen application 
made sure an nsmtp folder was not created in the mail folder pane as well in the 
file structure under mozilla. 
win98-2001-03-23-06
linux-2001-03-23-05
mac-2001-03-23-10
Status: RESOLVED → VERIFIED
Reopening as I'm still (or again?) seeing this bug after compacting folders on
build 2001033020 Win2k.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Can you list the steps ?
I have 30 folders for my POP account plus some subfolders and sub-sub-folders.

1. I did "compact folders" from the File menu.
2. (Mozilla took a few minutes to compact all my folders.)
3. I closed Mozilla and restartet it.

After this, I had some nstmp files on my disk in various mail directories.
I feel there is a link with bug 72457 (maybe as well bug 70322).
*** Bug 72457 has been marked as a duplicate of this bug. ***
looks like this problem is happening on win2k. Adding pp keyword. Changing 
platform and lowering severity.
Keywords: pp
OS: All → Windows 2000
Priority: P2 → P3
lowering serverity and priority.
Severity: major → normal
Priority: P3 → P4
Win2K is a pretty major platform!  Can we get confirmation it only occurs on 
Win 2000?  What about ME or XP?
Priority: P4 → P2
Target Milestone: mozilla0.9 → mozilla0.9.1
Marking worksforme using today's debug build on win2k. I used a new 
profile and compacted all folders using "Compact Folders" under File menu.
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → WORKSFORME
Sorry to be a bother, but reopening again. When I compact a folder, I get either
a) a properly compacted folder, or
b) an unchanged folder, and the "nstmp" folder (containing the compacted data)

Looks like about 50% of the time I try it. This problem occurs only if
compacting actually could do anything (i.e. there are deleted messages in that
folder). Occasionally, I crash on compacting (I'll get a stack trace next time).

I'll attach a POP mail folder + msf file + resulting nstmp file (all in one ZIP
file).
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
The ZIP file also contains the resulting nstmp file. I've seen this problem on
2001041104 Win2k.
Rename the nstmp file to the "security" and delete the security.msf file, then 
try again. 

Any corruption that has been caused by an earlier build, cannot be solved by
just using a new build. 

I have tested umpteen times and it worksforme!!!!
How can I get rid of the corruption for a folder? By deleting the *.msf file?
Yes delete the msf file. 
The problem seems to have nothing to do with a corrupt .msf file. I now have reproducible list of steps:
1. With Mozilla closed, put POP mail folder (I'll attach it) into your mail folder directory.
2. Start Mozilla.
3. Select the added folder. Mozilla will build the .msf file.
4. From the mail folder context menu, select "compact this folder".
5. Exit Mozilla.
6. Look into the the Mail folder - the nstmp file should be there.

I tested this with 2001041408 installer on Win2k. This problem occurs most of the time.
I reproduced the steps you outlined above using build 2001041508 on Windows 2000 
with a test POP account. I saw no nstemp folder. I even deleted messages, and 
then compacted, re-launched, logged in, and still saw no nstemp folder. To get 
this test POP3 account, I just added it to my already exisiting profile...
*** Bug 76802 has been marked as a duplicate of this bug. ***
As reported in #76802,
Build: 2001041904
Platform: Win2000
POP Inbox file of 75 MB (hadn't been compacted and had deleted messages back to
1998) a few (5 or 6) messages remained undeleted - Compact folders via right
click menu or File menu item would generate the nstmp file but left the original
Inbox intact rather than replacing it.  I haven't had this problem with small
folders, or those with few deleted messages.
I was only able to reproduce this in a case where compaction failed to finish. 
If compaction fails is there no way to recover than to have an nstmp file left
hanging around?
I believe I fixed this with my checkin on Sunday. If you see it with builds from
Monday or later, let me know.
Assignee: naving → bienvenu
Status: REOPENED → NEW
I think we should create the nstmp file in a place like c:\temp. This will avoid 
clobbering an already existing folder nstmp and also if moz mail crashes it will 
not be seen by the user, when he/she brings up mail again. 
That's a possibility - here's the disadvantage of that approach:  when we rename
the tmp file back into the original folder, if the temp directory is on a
different physical drive, that renmae will be a whole file copy, which can be
expensive.
How about moving the location to the same level where the server folder exists.
that's a possibility - however, I think I've fixed this bug. We were not able to
remove the nstmp file because we hadn't closed it in the error case. I fixed
that. If there's a folder called nstmp, we should use a different name for the
temp file anyway.
I'm using the 5/2 build.  I compacted my local folders.  I closed the mail
window in the middle of compaction and then exited Netscape.  When I started up
again there was an nstmp folder in my local folders.
well, that implies that closing a window with a running url isn't stopping the
url(s). That's a little hard to believe, but I'll try it.
Marking dependant on:

bug 70322 compact folders uses hardcoded temp file name "nstmp"
bug 77113 Compacting local folder crashes mozilla and destroys folders, Trunk [@
morkRowObject::CloseRowObject]
Depends on: 70322, 73564
I don't see how they're dependent on each other - the problem was that we
weren't cleaning up the temp file in some situations - I've fixed most of those
situations.
No longer depends on: 70322, 73564
I tried Scott's steps (start compacting a very large folder, and close the app
while it's compacting). I didn't see an nstmp file upon restart. Could you try
this again, Sheela, or Scott? I did verify, however, that we're not stopping
urls when a window closes (we should do that, don't you think, mscott?)
I was able to reproduce this using the 5/9 build

Here's some info.  My sent folder is about 17MB with 2000 messages.

I tried this 4 times before I could reproduce.  I think the one time I made it
happen, my Sent Folder was the selected folder.

All I did was select my Sent Folder, compact folders, Exit app.  When I
restarted, I had an nstmp folder.  
Bienvenu,
I used today's buildid 2001050906 on win98. I tried compacting my bugzilla 
folder where I filter all the bugzilla bugs. The folder size was about 8MB with 
about 5000+ messages.  I did compact folders from the menu item 4 times.  I am 
not seeing any nsmtp created when I close the application and launch again. I 
checked both in the app as well the file structure in explorer and did not see 
nsmtp.  May be my folder size was not big enough:(    
Using 2001050515 (0.9) on Win2k, I consistently get either a crash on compact
folder or it just never finishes... even in a folder that only has a few
messages in it.  When it doesn't finish, if I close and re-open Mozilla, there
is the nstmp folder in my mail account.  When it crashed, there was also a nstmp
folder.  The problem, in my perception, is that it is not finishing the
compacting - it seems to be creating the nstmp file but not replacing the
original mail folder file with it.  The only cases in which I *was* successful
in compacting were when I had either an empty folder or a folder that I had
deleted only one or two items from since the last successful compaction.
moving to 0.9.2 but if you're able to get to this this before, then go for it.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
r=naving
sr=mscott
Note: if we crash during the compact, (which I can't reproduce), we will still
leave the nstmp file.
fix checked in - any crash bugs would be separate bugs.
Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Buildid: 2001052304 -windows 2000
I verified this bug on stephen's machine.  Created a new folder and copied about 
5000 messages. The folder size was about 11MB. Deleted about 2000 messages and 
'compact this folder' from the context menu. Quit 3 pane while compacting. Did 
not result in a crash. Closed the application and launched again. Verified no 
nstmp was created in both profiles and 3 pane after launch.  Tried do the above 
twice but could not reproduce the crash and no nstmp was created. Later made 
sure 'compact this folder' worked fine and it reduced the file size to about 
7MB.
Marking verified.  Log a new bug when you crash while compacting and if it 
leaves the nstmp file as bienvenu mentioned.  
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.