User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0 Build ID: 20130307023931 Steps to reproduce: Selected a set of 2009 emails, right clicked and selected "archive" The selection was on Account2. I have multiple accounts. Of the two accounts relevant, here, Account1 and Account2 each had the Archive pointing to its own account, and set to annual. At the time of doing this, only account1 had archive folder, of 2 years (2011 and 2010). Account 2 had no archive folders. Timestamp: 3/16/2013 12:52:14 PM Error: Component returned failure code: 0x80550013 [nsIMsgFolder.deleteSubFolders] Source File: chrome://messenger/content/folderPane.js Line: 2196 Actual results: Although the emails were on account2, TBird created a new folder for 2009 in Account1, and stored the emails there Before testing, again, with a single selection, with the same result, I emptied and deleted the archive 2009 folder, successfully. After a later test, when I attempt to delete the folder, and after the delete confirmation dlg box, TBird throws an alert saying that there is already a folder by that name. This continues after a restart. These two errors appear in the error console: (on 3 and 2 occasions, respectively, in keeping with the subsequent attempts to delete) Timestamp: 3/16/2013 12:52:14 PM Error: Component returned failure code: 0x80550013 [nsIMsgFolder.deleteSubFolders] Source File: chrome://messenger/content/folderPane.js Line: 2196 Timestamp: 3/16/2013 12:53:08 PM Warning: XUL box for _moz_generated_content_before element contained an inline #text child, forcing all its children to be wrapped in a block. Source File: chrome://messenger/content/messenger.xul Line: 0 Expected results: Should have created a 2009 folder in Account2, and stored the emails in that folder. I don't see anything awkward about where the 2009 subfolder is stored
As seen in UI for Archive setting of Copies&Foler of each account, and as known by bug 819392,"Archive seting" is "per identity setting" instead of "per account setting". And identity selection is based on mail headers and identity definitions. So, "which identity's Archive setting is used" depends on: - Each identity's Archive setting(Archive folder, granuality) - Email address(identity) in mail(To:, CC:) - Delivered-To: header in mail - X-Account-Key: header in mail(downloaded via POP3) - X-identity-Key: header in mail(draft) Check aboves. Same problem as bug 819392? Do you use different Archive setting for different identity of same account? Do you use different Archive setting for same mail address(different identity number) of different account?
(In reply to john ruskin from comment #0) > After a later test, when I attempt to delete the folder, and after the delete confirmation dlg box, > TBird throws an alert saying that there is already a folder by that name. "Delete folder" is "Move folder to Trash" and "Folder name in Trash" is "lowest part of folder structure of deleted folder". For example, "Delete A/X" and "Delete B/X" tries to create Trash/X, and Tb warns you when X is already used under Trash. Do "Empty Trash".
(In reply to WADA from comment #2) > Do "Empty Trash". That was it. Trash was not expanded, so I didn't notice the pre-existing folder name. I would offer the suggestion (to someone) that a modification of the DLG throw should, instead, request authority to move the folder "FName" to trash with the appended (n), in the form "Fname (2)", "FName (3)".
WADA, your comments started a review tact which led me to these comments: 1. I have imported mail from other machines -- this, not an uncommon maneuver (due to new/failed machines) 2. I get email from various email addresses, and sometimes the senders use the wrong account. I move mail to the folder on which it should have arrived, and where I can expect to find related mail. 3. I sometimes send mail from the wrong email account, and move it to the correct sent box. Intuitively, I would have expected an auto archive feature to move mail from the FolderTree where it was sitting, to the archive by year for that FolderTree. The complex decision tree that the other bug report demonstrates, and your comments at Comment 1, are both unexpected. I have only one identity (if I understand that correctly) per account, and various AccountsN set up. As it turns out, the 2009 emails were mailed to what was, at one time, Account4 (based on the X-Account-Key in the email). That precise email account/address is now Account7 on my current Thunderbird. From what you are describing, the move I encountered is as programmed. Whether that is wise, is the issue. So, to answer your question, this and the other but appear related, but not quite. I would re-state my issue to something simple: The archiving should be simple -- for each individual email, Archive to the Archive-Folder, within the FOLDER TREE where the email is sitting at the time. That behavior can be triggered by a simple CkBox, which would read "Archive to Current Folder Tree", found within the account set up. Leaving it unchecked would engage the complexity you detail. The complexity of reviewing an individual email for anything more than the placement in the FolderTree, and then the SENT-DATE (ie, looking at the Account-Key, and so on) for most users would likely be unnecessary. The engineer in me has expected, since TBird's inception, the folder-tree archive, intuitively and I am surprised at how the thing is so far from that. I suspect that adding a check box to the UI, and when checked making the move by Folder-Tree, wouldn't be a huge project, and would engage coding myself, but my TBird coding is useless...
Here is bugzilla.mozilla.org to report Tb's flaw in code to developer. Here is never support forum, so there is no need to state about your problem by lengthy words. Required data for problem analysis is; - Your Archive setting of each identity - Message headers of mail relevant to Archive operation of Tb; - Mail which is moved to Archives folder as you expected - Mail which is NOT moved to Archives folder you expected These are already mentioned in bug which I already pointed in my previous comment.
I still think it is a bug, and a different, narrower context from bug 819392, as I have only one identity. Perhaps another statement for the bug is that the UI does not state that the Archive is by the emails' internal content ?
(In reply to john ruskin from comment #6) > as I have only one identity. You said "you have two accounts, account1, account2" in comment #0. Does the "one identity" mean "one identity per account"? Or two accounts is "one pop3 account with one identiy" and "Local Folders which doesn't have associated identity"? Please note that "requesting data like 'Your Archive setting of each identity'" is to avoid needless questions like this to know about your environment where your problem occurs. > Perhaps another statement for the bug is that the UI does not state > that the Archive is by the emails' internal content? (1) If "one identity per one account in Tb" and while user looks "primary Copies&Folders setting" only, user's understanding and/or expectation is "Archive == per account feature" which works independently in an account. (2) However, when user downloads mails via POP3 and when X-Account-Key: header is written in mail data by Tb, and if user moves mails to other account's folder or if user uses Global Inbox, user knows "Archive may move a mail to archive folder of other account" due to "X-Account-Key: based idetity selection by Tb". (3) And, once user defines "multiple identities of an account", user sees "per identity Copies&Folders setting tab/panel", and user knows that "per idetity archive folder choice" is possible at the ""per identity Copies&Folders setting tab/panel". After it, user's expectation is changed to "Archive==per identity feature". As written in bug 819392 and as seen in bug pointed by that bug, "Tb's behavior in Archive" depends on conditions, and it looks inconsistent sometimes for users. I can say that Tb's Archive behaves as coded. But I can say nothing about "correct Tb's Archive behavior", because I don't know what is design of Tb's Archive feature, and because I don't know whether "official and docuented design of Tb's Archive feature" exists or not.
If there is a demonstrated case which isn't bug 819392 then we could reopen. But for now it just sounds like bug 819392
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 819392
You need to log in before you can comment on or make changes to this bug.