User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 Renaming an IMAP folder for example using special characters like german umlauts fails on Thunderbird 3.0.2 showing up the error message "[...] Maibox does not exist" if you click on it. This just works flawless using Thunderbird version 2.0.0.23. The folders results in both version to the same name on the server (Cyrus 2.2). After restarting Thunderbird the renamed folder is usable again. The new offline imap mode is not active! Example: folder "test" renamed to "test ä", seems to work fine on first sight, but now try to click on the folder -> error message appears Reproducible: Always Steps to Reproduce: 1. create a folder "test" 2. rename the folder to "test ä" 3. click on that folder Actual Results: error message "[...] Maibox does not exist" appears Expected Results: no error message

Can you get IMAP log and check IMAP level flow for the rename & open? > https://wiki.mozilla.org/MailNews:Logging If Tb's fault is seen in log, attach(never paste if long data) to this bug, please.

Problem was reproduced with Tb 3.0.2 on MS Win XP-SP3 using Gmail IMAP.

Checked under Japanese MS Win-XP SP3, system charet=Shift_JIS. 1. rename XYZ/test to XYZ/test ä ("test ä" is copied at this bug, and pasted at rename UI of Tb) 2. Click XYZ/test ä => Error 3. Folder properties of XYZ/test ä => Error again > Location: imap://yatter.one%40gmail.com@imap.gmail.com/XYZ/test%20%C3%A4 Current URL is next. Modified UTF-7 is correctly used in currentUrl. > imap://yatter%2Eone%40gmail%2Ecom@imap.gmail.com:993/rename%3E/XYZ/test%3E/XYZ/test%20%26AOQ-: = currentUrl 4. Unsubscribe XYZ/test ä 5. Subscribe XYZ/test ä 3. Folder properties of XYZ/test ä => No error > Location: imap://yatter.one%40gmail.com@imap.gmail.com/XYZ/test%20%26AOQ- Folder name of modified UTF-7 passed from server is correctly used.

(1) Rename is correctly requested with modified utf-7. > 00000067 24.13363838 ... ProcessCurrentURL:imap://yatter%2Eone%40gmail%2Ecom@imap.gmail.com:993/rename%3E/XYZ/test%3E/XYZ/test%20%26AOQ-: = currentUrl > 00000074 24.37368011 ... 9 rename "XYZ/test" "XYZ/test &AOQ-" > 00000076 24.58089828 ... 9 OK Success > 00000077 24.58253479 ... 10 subscribe "XYZ/test &AOQ-" > 00000079 24.79115677 ... 10 OK Success (2) currentUrl just after rename is wrong. > 00000086 101.45420837 ... ProcessCurrentURL:imap://yatter%2Eone%40gmail%2Ecom@imap.gmail.com:993/select%3E/XYZ/test%20%C3: = currentUrl Note: %A4 in Location: of test%20%C3%A4 looks to be lost. (3) select after rename is wrong (charset of windows-1252 is set for attached log data) > 00000102 102.12757874 ... 4 select "XYZ/test Ã" > 00000104 102.23823547 ... 4 BAD Could not parse command

Note: If unsubscribe and re-subscribe is executed, Bug 520437 occurs. > Bug 520437 Garbage file/directory of {foldername}-{suffix}.msf > and {foldername}-{suffix}.sbd is created upon each unsubscribe / subscribe

Good catch; thanks for the triage & nomination! Adding regressionwindow-wanted, as it's likely helpful to understand exactly what code change introduced this.

"unsubscribe and re-subscribe" was not needed to recover. "collapse account, then expand account again" was sufficient to recover.

Bug 499278(Target Milestone: Thunderbird 3.0b3) is for problem in rename to "Köln". Problem is that create "K&APY-ln" is properly issued but folder pane display becomes "K&APY-ln". This bug looks for me remainig issue even after fix of Bug 499278. As for me, I didn't verify Bug 499278 after fixed. I probably executed fix verification test of Bug 499278 in this bug (i.e. fix of Bug 499278 was insufficient for complete resolution).

create "K&APY-ln" -> rename "original" "K&APY-ln". sorry for spam.

Tested according to comment 3 using steps 1-2. Regression range 1: works: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090212 Shredder/3.1a1pre 2009-02-12-03-comm-central-trunk broken - produces "test &AOQ-", no error. Gmail appears to render as "test ä": Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090213 Shredder/3.1a1pre 2009-02-13-03-comm-central-trunk http://hg.mozilla.org/comm-central/pushloghtml?startdate=2009-02-12+02%3A00%3A00&enddate=2009-02-13+04%3A00%3A00 Regression range 2: broken - produces "test &AOQ-", no error. Gmail appears to render as "test ä": Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090629 Shredder/3.1a1pre 2009-06-29-04-comm-central-trunk broken - "The current command did not succeed. The mail server responded:Could not parse command": Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090701 Shredder/3.1a1pre 2009-07-01-03-comm-central-trunk http://hg.mozilla.org/comm-central/pushloghtml?startdate=2009-06-29+03%3A00%3A00&enddate=2009-07-01+04%3A00%3A00

> http://hg.mozilla.org/comm-central/log?rev=499278 > searching for 499278 > bfb804e8b147: fix imap rename when new name required imap mod-utf7, r/sr=standard8, 499278 > David Bienvenu <bienvenu@nventure.com> - Tue, 30 Jun 2009 07:52:54 -0700 - rev 2980 > fix imap rename when new name required imap mod-utf7, r/sr=standard8, 499278 This bug is not regression. After fix of bug 499278, Tb goes ahead, and problem is morphed to this bug.

Above comment is for Regression range 2: in Comment 10. For Regression range 1, regressed by following change? > Thu Feb 12 17:20:51 2009 -0800 1ceaf63561e2 David Bienvenu > — fix handling of imap folders with non-alphanumeric chars like # in name, > r=standard8, sr=neil, 115091 > Bug 115091 Mail subfolder(IMAP) can not have a # sign in the name.

Thanks for the regression hunting, Matt! Tracking down which code changes are related to a problem is super helpful.

When I tried this, I was able to select the renamed folder after a restart. Is that not the case for others on this bug? I suspect WADA is right and this is not a regression and I suspect not really a blocker by the criteria we've established for blockers...

@David: you're right, after a restart everything works fine and you are able to select the folder - but that's surely not a suitable workflow ;)

Yeah, it's definitely an unfortunate bug, and I will try to fix it, but I'm not sure it's a 3.1 blocker...

(In reply to comment #15) spadge@gmx.net, read comment #7, please.

This should fix it. Now I need to write a unit test...

writing unit test is complicated by the fact that imap fake server doesn't seem to implement RENAME correctly.

Comment on attachment 436051 [details] [diff] [review] proposed fix The easy part is making sure we convert imap mod utf7 to utf8 before looking up the folder, and converting unicode to imap mod utf7 before setting the online name. In order to write the unit test, I had to fix the imap fake server's rename function.

If I evaluate top.opener.msgWindow.openFolder.URI in the Error Console I get imap://neil.rashbrook%40googlemail.com@imap.googlemail.com/[Google Mail]/&IKw- Is that expected?

Is that for a newly renamed folder, before restarting, with the patch? What's the unicode name for the folder?

Comment on attachment 436051 [details] [diff] [review] proposed fix I should have checked the URI before and after renaming ;-) [In my case the folder name was £ or € since those are the easiest non-ASCII that I can type!]

fix checked in.

Comment on attachment 436051 [details] [diff] [review] proposed fix would be nice for 3.05

fixed for 3.0.5