266296 - temporary search 'folder' should not be placed alongside other folders

Status: RESOLVED WORKSFORME

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Eyal Rozenberg]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040927
Build Identifier: 

For some reason it seems MailNews is creating a temporary mail folder during
message search, placing it alongside real folders in the mail folders'
directory. But what happens if there's a crash? The user gets to see a
supposedly-nonexisting folders, which he/she cannot even delete using the UI (I
tried to delete it; didn't work; manual deletion worked), and may crash MailNews
again (happened to me once; second time there was no crash).

The temp folder should be put in a temp directory.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Eyal Rozenberg]

Ah, sorry, it seems I spoke too soon. this folder regenerates even after I close
Mozilla, manually delete it and its msf, and restart. Its name is the name of
the folder I was searching in with the prefix 'search-view'. Searching the
folder, or other folders, again does not make it go away.

Comment 2

[David :Bienvenu]

we store the virtual folders list in virtualfolders.dat, at the root of your
profile. But you should be able to delete virtual folders, if they show up in
the UI. 

Comment 3

[Eyal Rozenberg]

(In reply to comment #2)
<But you should be able to delete virtual folders, if they show up in
> the UI. 

Well, I wasn't able to. Had to delete the folder manually from both
virtualfolders.dat and the mail folder.

Comment 4

[Jay Patel [:jay]]

Related to bug 267345?

Comment 5

[Eyal Rozenberg]

Related, but not a dupe of, since what I was thinking was that the virutal
folder should simply not be created as one of the user's mail folder, but rather
elsewhere - somewhere really temporary.

Comment 6

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614