User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1
my imap server has a trash named "trash". mozilla thunderbird creates a trash
folder named "Trash" (uppercase). this leads to problems using the web interface
to my email account. why doesn't thunderbird check as well for lowercase trash?
Steps to Reproduce:
creates "Trash" folder (uppercase)
Use "trash" instead (lowercase)
my imap server has a similar folder... can a option be added to manually select
the trash folder, ie on other servers that i have used they used "Deleted
Messages" for the trash folder.
My girlfriend has an IMAP server that has a lowercase "trash" folder. She uses
the "delete is move to trash" delete model, and when she deletes a message, it
is not copied to the trash server, but lost (undo recovers it).
Maybe Thunderbird was not recognizing the lower case "trash" folder and
attempted to create a "Trash" folder. The server refused this (maybe it's a
Windows box with a case-insensitive filesystem), and the message was copied to
I'm sure Thunderbird was not recognizing the "trash" folder as its trash folder
because its icon in the folder pane was a normal folder icon, not a trash icon.
This is using the 20031024 trunk thunderbird on Windows XP.
I manually specified the trash folder to be "trash" (using the hidden pref in
bug 24064), and everything seemed to work: the proper trash folder icon appeared
and messages were correctly deleted. Then I removed the hidden pref, and
everything continued to work! Weird.
More investigation coming.
Regarding comment #1: set the hidden pref mail.server.server?.trash_folder_name
to change the name of the folder that Mozilla uses as a trash folder (see bug
Created attachment 135016 [details]
IMAP log, "trash" != "Trash"
Ok, this is what happens. On startup Thunderbird tries to create "Trash", but
the server answers "NO mailbox already exists" because there is already a
folder called "trash" and the server is case-insensitive (this may be a bug in
the server). When I delete a message, Thunderbird just sets the deleted flag on
the message without moving it to the trash folder because it thinks the Trash
folder is not there.
If you point Thunderbird to the "trash" folder by setting the hidden pref
mail.server.server?.trash_folder_name, Thunderbird uses this folder as a trash
folder and everything works. If you remove the preference, everything still
works because the fact that it's a trash folder is stored in the local
trash.msf file. If the local msf file is deleted, the problem reappears.
The server on which I created the log file has a trash folder that is not
recognized as such by thunderbird because it's not "Trash" but "trash".
This is what I did while logging:
- Log in (1 message in inbox)
- Delete message (delete is set to move to trash)
- Open "trash" folder to see if it's there (no messages in trash)
- Go back to inbox, Undo delete message.
A possible solution to this is to look for something that looks like "Trash",
using a case-insensitive match, when listing folders immediately after logon. If
we find something like it, and there is no "Trash" folder, use this folder as
the trash folder.
Does this make sense? CC'ing bienvenu for IMAP insight. :)
Note that this may seem minor, but it can cause dataloss if a user deletes a
message expecting to find it in the trash later, or deletes it by mistake! If
the user doesn't know about undo, or has expunge on exit, the message is lost.
This is made worse by the fact that there is no indication that something has
This also impact Laposte.net(French ISP), which use a TRASH folder.
This is really a big problem for new IMAP users, which are not able to understand why they have 2 different trash folders, and don't know which one of them should be deleted...
Changing importance to "major" since I also discover that this bug impact the biggest ISP in France: Orange and SFR.
After 3 pages of discussion, I don't succeed to make a user understand how he should set up its Trash folder on a SFR account: http://www.geckozone.org/forum/viewtopic.php?f=4&t=101028 :-(
folder case sensitivity bugs:
probably a dup - there's a patch in a bug to do case-insensitive lookups for special folders.
(In reply to David :Bienvenu from comment #10)
> probably a dup - there's a patch in a bug to do case-insensitive lookups for
> special folders.
It would be very great if this bug (from 2003!) or the original one could be fixed, because it is very a pain for orange.fr, sfr.fr or laposte.net Franch'users, and it is certainly not so difficult to fix.
I've requested a try server build for a trunk build of Thunderbird with a potential fix for this - I'll post a link to the builds when they finish.
patch is in Bug 546728 - this is probably a dup, or vice versa.
builds will show up here - http://firstname.lastname@example.org/ - if someone who experiences this bug with the French isps wants to try it and report back, that would be very helpful!
Just try your build, but unfortunately, Earlybird still create a "Trash" folder and don't use the existing "TRASH" folder on an imap.laposte.net account :-(
Vincent can you create a imap log when this happens so bienvenu can see what is still being done wrong ?
(In reply to caméléon from comment #15)
> Hi Ludovic,
> Just try your build, but unfortunately, Earlybird still create a "Trash"
> folder and don't use the existing "TRASH" folder on an imap.laposte.net
> account :-(
Did you use the try server build I pointed you to, or a nightly earlybird build? If the former, perhaps you could get me access to an account on that server that I could debug with?
Hidding the comment
I do have a fix for this, but getting the xpcshell test working/failing is proving difficult.
Just one question... Shouldn't we mark this bug as duplicate (or dependent) of 546728, because it seems to me that the fix in 546728 solve this bug.
Am I wrong?
(In reply to caméléon from comment #21)
> Just one question... Shouldn't we mark this bug as duplicate (or dependent)
> of 546728, because it seems to me that the fix in 546728 solve this bug.
> Am I wrong?
They're actually separate but related issues, which is why my first try server build didn't fix it for you. But I'm fixing both in one patch.
fixed by patch in bug 546728