User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b4) Gecko/20090427 Fedora/3.5-0.20.beta4.fc11 Firefox/3.5b4 Build Identifier: 3.0b3pre using Fedora 11-release of 3.0b3pre Upon renaming inside Thunderbird foldernames appear with specialchars as they are stored on the IMAP-server ("Köln" is "K&APY-ln"). Reproducible: Always Actual Results: e.g. "Köln" is "K&APY-ln"

Do the names fix themselves when you restart?

Does the "K&APY-ln" appear at folder pane of Tb? Or you are talking local file name of "K&APY-ln" which is created/used by Tb? If former, Bug 450754 is already fixed by Tb 3.0b1... New problem upon rename which should be listed in Dependency tree for Bug 497199? What is date of the "Tb 3.0b3pre"? If latter, read thru Bug 450754, please.

Folders created before / using a different program show up okay. Folders created with the new thunderbird even appear broken after restart, so I assume they are created wrong on the IMAP-server (worked with TB 2.x). Current version shipped for Fedora 11 claims to be: thunderbird-3.0-2.4.b3pre.hg.6a6386c16e98.fc11.x86_64

Phenomenon was observed with 2009.6.21 build. > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090621 Shredder/3.0b3pre When K&APY-ln was displayed as folder name after rename, name in folder properties was K&APY-ln, but Köln was properly displayed in subscription list. After two consecutive "collapse/re-expand of IMAP account", Köln was displayed at folder pane. No restart was required. Confirming.

I see this.

taking - I'll try to reproduce this

yes, ok, we're not converting back from imap-mod utf7 on rename. We are doing it correctly on new folder creation, so this bug is a little less serious than I thought...

the new name is in imap mod-utf7, so convert it correctly to unicode. If I had to guess, I would guess this broke way early in the 3.0 process, probably when we got rid of nsFileSpec, or perhaps did some of the string reworking.

Comment on attachment 385435 [details] [diff] [review] trivial fix >- CopyASCIItoUTF16(newName, newNameString); >+ nsCString utf7LeafName; >+ rv = CopyMUTF7toUTF16(PromiseFlatCString(newName), newNameString); >+ NS_ENSURE_SUCCESS(rv, rv); You're not using utf7LeafName. r/sr=Standard8 with that removed. A unit test would be nice, but not needed for getting this patch in.

fix checked in, with nit addressed. Yes, a unit test of all of our imap mod utf7 handling would be a good thing.