User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:22.214.171.124pre) Gecko/20090827 Shredder/3.0b4pre deleting an IMAP subfolder from trash does not remove the folder until restarting TB Reproducible: Always Steps to Reproduce: 1. Create an IMAP account. 2. Create a folder. 3. Delete it. 4. Make sure it is moved to Trash. 5. Now try to delete this subfolder. Actual Results: After being deleted it is still visible. Expected Results: The folder should be gone.
Sorry, it does not happen always.
Summary: deleting an IMAP subfolder → deleting an IMAP subfolder leaves the folder visible
Version: unspecified → 3.0
By that I mean the it is reproducible sometimes.
Tested it with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:126.96.36.199pre) Gecko/20090909 Shredder/3.0b4pre, the issue is still present.
Severity: normal → major
I just tried this and it WFM. Can you attach a protocol log showing a failing delete? https://wiki.mozilla.org/MailNews:Logging
I believe in some cases some piece of code is holding the db open and preventing us from removing the folder - but restarting should fix it, I believe.
Assignee: nobody → bienvenu
Flags: blocking-thunderbird3? → blocking-thunderbird3+
Target Milestone: --- → Thunderbird 3.0rc1
(In reply to comment #0) > deleting an IMAP subfolder from trash does not remove the folder until restarting TB Restart of Tb is really mandatory? This kind of issue is folder pane refresh/update issue in many cases. And, AFAIR, one of next was effective manual recovery procedure in many cases. (1) Collapse/re-expand, parent folder, account. (2) If (1) is not effective, open new Tb window, and close old Tb window. Context menu of account/folder, "Open". Is (1) or (2) effectibve in your environemnt? Does same problem occur with "Empty Trash"? By the way, I saw similar phenomenon by rename of Gmail IMAP folder with Tb 2009/9 /09 build. (1) was effective recovery procedure in my case.
I just tried it with: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:188.8.131.52pre) Gecko/20090913 Shredder/3.0b4pre and the issue is still present. I created a new folder called Folder to be deleted, which I then deleted and it was moved to Trash. After trying to delete it from there, the folder is still present. After a few clicks around in the program I get an alert: The current command did not succeed. The mail server responded:Mailbox doesn't exist: Trash.Folder to be deleted Restarting TB twice finally took the folder away.
okay, I created the log, how shall I send it to you? Do I need to sanitize it someway too?
I'm not sure that a log is going to be helpful here, since it's the local client code that's holding the db open. If I can't reproduce this, I might ask for a log...
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Created attachment 400816 [details] [diff] [review] proposed fix Make nsImapMailFolder::Delete tell all db listeners about the db going away, even if its cached db pointer has already been cleared. nsLocalMailFolder::Delete already does this.
Whiteboard: [has patch for r/sr standard8]
Whiteboard: [has patch for r/sr standard8] → [no l10n impact][has patch for r/sr standard8]
would be nice to get this reviewed and landed soon, because I believe there are a fair number of bugs that can be closed once this lands.
fix checked in - I'll try to find the various bugs that also are fixed by this...
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Whiteboard: [no l10n impact][has patch for r/sr standard8] → [no l10n impact]
(In reply to comment #14) > fix checked in - I'll try to find the various bugs that also are fixed by > this... Mozilla/5.0 (X11; U; Linux i686; nl; rv:184.108.40.206pre) Gecko/20090922 Lightning/1.0pre Shredder/3.0pre i don't see it fixed (the problem reported in bug 517419)
Mozilla/5.0 (X11; U; Linux i686; nl; rv:220.127.116.11pre) Gecko/20090923 Lightning/1.0pre Shredder/3.0pre not fixed
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
it's working here - I can't reproduce any issues, whereas it was easy to reproduce earlier.
Then is bug 517419 not a dupe of this bug
They both work here - if you're seeing 517419 but not 513012, then I would say your situation is not a dup. Are you seeing this bug, bug 513012?
(In reply to comment #20) > They both work here - if you're seeing 517419 but not 513012, then I would say > your situation is not a dup. Are you seeing this bug, bug 513012? I can delete a folder so i don't see this bug (anymore).
ok, I'll re-mark this fixed and undupe bug 517419.
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago → 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.