If a 3.0 user with a 2.0 profile with a Local Folders-1 account gets their mail sent to the Local Folders-1 smart mailbox account because of a faulty upgrade, we should try to recover the downloaded mail and put it into the Local Folders-1 directory with a name like Inbox-recovered. We'd need to do this in the code that detects the bad deferral. +++ This bug was initially created as a clone of +++ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; nl-NL; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 FirePHP/0.3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; nl-NL; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 I've upgraded tb2 to tb3. My old e-mail is in Local Folders. However, if I download new e-mails, they are stored in Local Folders-1. It's like tb tries to create a map Local Folders, and windows does so by suffixing it with "-1", the default behaviour in windows when you create a duplicate folder/file. So new e-mails don't show up, because tb reads from Local folders, and writes to Local folders-1. I've openened a thread (http://forums.mozillazine.org/viewtopic.php?f=39&t=1640085) but sofar nobody has seen this behaviour I think. I tried to delete Local Folders-1. This does not help, since when I fetch new e-mails, Local Folders-1 is created again and the new e-mails are stored there.

I don't know if I'll be able to get this done before the code freeze for 3.01, but nominating anyway.

Ugh, my test case for this bug is stubbornly refusing to download mail into the smart mailboxes inbox, which makes it hard to test the recovery code. I just get errors on the console in getNewMessages. I know some users have been seeing that same issue, which is good in the sense that their mail isn't getting downloaded and hidden, but bad for testing the recovery code. (this is testing with 3.0, not 3.01 candidate, which as of right now just fixes the bad deferral)

Because there was only one actual account (Local Folders), smart folders weren't getting created, so there was no Inbox to try to download to.

This patch works for the basic case - I manually horked a 2.0 profile and ran 3.0 against it, downloaded some mail which ended up in the local folders-1 directory, and then ran a build with this patch in it, and it copied the e-mails to the local folders inbox on first run, and left them alone on subsequent runs. Since the affected code only runs when we have accounts deferred to a hidden account, and the code fixes that, we shouldn't end up copying the lost messages over and over again, which was a slight worry. An alternative is to create a new folder with the reclaimed messages, but I can't name that in a localized way, and I think the user experience is better this way. I'll try to extend the xpcshell test to test this code. This patch as written has to be in 3.01 to work, since it does its work in the deferral repair code, and if 3.01 ships the deferral repair code, but not this code, then this new code will have to be hooked up differently. The nice thing about doing it in the deferral repair code is we don't have to worry about the code running multiple times.

writing a test for this is challenging, since I need a way to create a folder and the corresponding db *before* the accounts are loaded...

Comment on attachment 420841 [details] [diff] [review] proposed fix r/sr/a=Standard8 I've done this by intense code inspection. I suggest we try and get some people to test this during the 3.0.1 beta phase.

fixed on trunk.

fixed for 3.01 Roland, I'm thinking if we see more people on Get Satisfaction with this issue, we could point them at 3.01 rc builds (should be one coming out tomorrow) and see if it fixes the issue for them. I'm sure Standard8 will announce the availability of 3.01 candidate builds once they're available. I'm happy to help you tell people how to try the builds...