new trash folder is created but not used



16 years ago
10 years ago


(Reporter: allltaken, Assigned: Bienvenu)


Windows 98

Firefox Tracking Flags

(Not tracked)




16 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130

I prefer to back up Trash by renaming, just as I back up other mail files. I
renamed Trash.* to Trash02.* with Mozilla not running, and using a DOS window
instead of Windows Explorer which adjusts links when some file actions are done.
Then I started Mozilla 1.2.1, downloaded the POP3 mail and deleted the spam. The
deletions went into Trash02 instead of the newly created Trash folder, defeating
the purpose of trying to close out one trash folder and start a new one. Note
that the count of unread msgs in a folder is shown but not necessarily correct
until you open the folder. 

Reproducible: Always

Steps to Reproduce:
1. With Mozilla not running, rename Trash.* to Anothername.* which renames the
.msf file too. 
2. Start Mozilla, click on Anothername to update the info about it, and 
verify that a new Trash has been created and is empty.
3. Select a file to delete, perhaps a test file in Drafts, or some actual spam.
You can mark it as unread so you can more easily see where it goes.
4. Delete the selected message.

Actual Results:  
The deleted message is moved to the old trash folder now called Anothername.

Expected Results:  
Mozilla should put the deleted file in the folder named Trash.

A workaround might be to copy the trash folder and then delete it.

I think there has been at least one suggestion that standard folders like Trash
not be automatically created if they don't exist. But this is the behavior of
previous versions of Mozilla or at least Netscape 4.x and I like it. Shouldn't
panacea.dat have info on the name and location of the trash folder?

Also, in studying the contents of panacea.dat in my profile, I noted that it
contains old out-of-date info on the location of my mail files. Is there any
purpose in keeping that location history, or is it just needless clutter?


16 years ago
QA Contact: gayatri → esther


16 years ago
Ever confirmed: true

Comment 1

16 years ago
Several other standard folders used by Mozilla (Inbox, Sent and possibly others)
that I would expected to be hard-coded in Mozilla are evidently "aliased", not
hard-coded. I tried to create backup copies of Inbox and Sent with different
names, and then delete Inbox and Sent so the program would create a new Inbox
and Sent, but the backup Sent box (named Snt028) still appears with the old name
"Sent" so that there are now two "Sent" boxes in the mailbox list. I named the
old  Inbox to "Inn028" and it still appeared as "Inbox" along with a new Inbox.
After naming the old file to "Innn028", it appeared with its real name, but with
the location in the list (right after Inbox) and icon to indicate that the
program thinks it's an inbox instead of an extra user-created file to be listed

The Mozilla config info showing on entering "about:config" as a URL in the
browser window says nothing about Inbox. It also appeared that there were legacy
variables in the variables list that apparently are not used. Some may be from
Netscape 6.x or even 4.x.

But there was no indication of how the program was tracking changes in the name
of Inbox and Sent even while Mozilla was not running. Where are the real and
aliased folder names being stored? What happened to hard-coded names?

Sorting mail with a filter includes keeping track of name changes somehow so
that filtered mail goes to the same but renamed folder. This complicates
renaming a folder to a backup name and starting a new one with the same name.

Why doesn't Mozilla use hard-coded names (Inbox, Sent, Trash, Drafts, Unsent,
etc)? for each account? Having aliased folder names makes backing up mail very
Product: MailNews → Core
QA Contact: esther → database
->WFM on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008030103 Lightning/0.6a1 Thunderbird/3.0a1pre ID:2008030103
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME

Comment 3

11 years ago
Phil, I notice you're marking a lot of mailnews bugs as database bugs. I had been considering database bugs to be those concerned with the .msf files, i.e., the message index, but you're marking any bugs having to do with mail files on disk (e.g., mailbox bugs as database bugs). I'm not saying I'm against the redefinition of database, but I just wanted to make sure you knew you were changing it :-)
Not I, said the fly. Unless I actually moved some since you told me I was wrong last summer that I've forgotten, I think you're just seeing the bulk QA contact change on the 61 bugs that were some random to the default watchable QA contact. Certainly that's what this bug was - says it was filed here, *you* confirmed it ;), and then the change to the watchable QA had the desired effect, making it possible for someone watching it to do some QA.

Comment 5

11 years ago
oh, yes, it's just the QA contact getting changed - sorry!
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.