70322 - compact folders uses hardcoded temp file name "nstmp"

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect)

Description

[J Luh]

I've experienced occasional (hard-to-reproduce) crashes when compacting folders
with Mozilla 0.8 2001021502 on Mac. I am not very familiar with the Mozilla
source and don't know whether this is causing the crashes, but I noticed the
temp file name seems to be hardcoded in as "nstmp" rather than generated:

http://lxr.mozilla.org/seamonkey/source/mailnews/base/src/nsMsgFolderCompactor.cpp#224

Could this cause problems when the nstmp file already exists?

Comment 1

[lchiang]

should compact folders go to naving?

Comment 2

[Bradley Hart]

Confirming to get this issue some attention.

Comment 3

[Navin Gupta]

reassigning to self. I think this may have already been fixed. 

Comment 4

[Navin Gupta]

Resolved worksforme using mac build 2001040208

Comment 5

[J Luh]

I haven't been able to try more recent daily builds, but I have experienced this
crash with Mozilla 0.8.1--crash when I tried to compact a large folder while
another "compact folder" operation was running on another large folder (and the
nstmp file already existed). Also, the code on lxr.mozilla.org still uses the
hardcoded "nstmp" filename.

http://lxr.mozilla.org/seamonkey/source/mailnews/base/src/nsMsgFolderCompactor.cpp#264

Comment 6

[J Luh]

The 2001041908 Mac binary still uses the hardcoded file name "nstmp." If you
have a file named "nstmp" in your mail folder, it will clobber the file.

Comment 7

[Navin Gupta]

Yes we use hardcoded nstmp file and it will clobber a folder with that name, if 
it already exists. Accepting...

Comment 8

[Seak, Teng-Fong]

I've seen the same problem too, even with the latest 20010423 (I'm using Win2k,
so this might be a problem for all version, not just Mac).

Moreover, I've been trying to compact a small 600KB save folder (which should
become about 20kB after compacting) but Mozilla never succeeded. I don't know if
Mozilla really takes more than few minutes to compact the folder, or it has got
a bug that it'll never finish compacting, because right now it's still
"compacting" the same folder and the status bar (on the bottom of the mailer
window) is still just 1/3 finished!

Comment 9

[Michael Wardle]

I saw this today in 2002040708 on Win32 just after compacting folders.  I'm also
having other problems with my mail, including a regression on a bug I can't find
right now.

I also installed Netscape 6.2.2 on the same host today, so it *could* be related
to this, however I seldom compact folders, so I would suggest this bug may still
be present.

Comment 10

[Ron Thigpen]

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.  

I deleted Inbox.msf, renamed nstmp to Inbox and restarted Mozilla.  Mozilla
rebuilt Inbox.msf and the Inbox was restored. 

Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020818

Comment 11

[Navin Gupta]

I have a patch to fix the problem that was first reported (patch in bug 166617)

Comment 12

[Navin Gupta]

fixed

Comment 13

[Navin Gupta]

The patch in bug 166617 was checked on 1.0.2 branch.

Comment 14

[esther]

Using a branch build dated 10-03, when compacting several times quickly several
folders, I received individual alerts for each folder being compacted that the
folder were in use.  I OK'd the dialogs and when all was done, I had 3 temp
folders. (nstemp-1, nstemp-2 and nstemp-3)  This would verify the fix that when
trying to start another compact process while compacting is going on, we don't
overwrite the nstemp file. (see comment #23 in bug 166617.  
Note, with trunk build 20021011 on winxp I can't get into the state I just
mentioned. I believe another fix went into the trunk that handles the multiple
requests to compact.  see fix in bug 73357

verified in branch 20021003 for first problem, verified for trunk 20021011 that
I can't even get to the original scenario anymore. 

Comment 15

[esther]

I could not reproduce the original reported bug crash, however it is very old
and there have been compact bug fixes since it was reported and before this
particular bug fix. I have run the test scenarios noted in bug 173399 on
mac 9.1 and winxp for this bug fix.  Here is what I have tested for this bug:

1.) Clicking Compact Folders multiple times while compacting is in progress for
the Inbox = OK, I received the expected message: "The folder "xyz" cannot be
compacted because another operationis in progress.  Please try again later."  I
OK the error and compacting continues without losing msgs or corrupting the msf
file or without leaving temp files around.

2.) Clicking on Compact Folder multiple times while compacting of Inbox and 2
other  folders is in progress = OK, I received the expected message: "The folder
"xyz" cannot be compacted because another operationis in progress.  Please try
again later."  I OK the error and compaction continues.  I click Compact Folders
again while the compacting is still going on this time in another folder.  I get
the appropriate error msg.  I continue this until I don't get the error msg
anymore and then I check the folders that were compacted.  They are all OK. No
temp files left lying around.

3.) Clicking on OK for the automatic compact notice for POP account while POP
Inbox is getting messages.  I get the error notice, OK'ing it.  Result all
folders OK. No temp files left lying around.

4.) Clicking on OK for the automatic compact notice for POP account while IMAP
Inbox is getting messages.  =  OK. No temp files left lying around.

Verified in Branch left over part of the bug.  This is now completely fixed for
branch 20021017.  

Comment 16

[esther]

Since this is verified in both branch and trunk builds marking this bug Verified
in addition to changing keyword to verified1.0.2