User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030227 Phoenix/0.5 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030304 Stuff: Special mail folders (Drafts, Templates, Sent) should be deletable if they are not used, or so I gather from bug 33235 -- I'd sure like to get rid of some of my Drafts folders and all of the Templates folders... 'Not used' means that none of the mail accounts' 'Copies & Folders' prefs direct any messages to them. Problem: If a special folder is successfully deleted, it is recreated on restart. A special folder cannot be deleted again before toggling the relevant 'Copies & Folders' settings back and forth. Reproducible: Always Steps to Reproduce: 1. Create new profile, launch mail, goes to acct wizard; create a POP account 2. Try to delete Sent folder on the POP account -> FAILS, this is as designed, I think. 3. Edit > Mail & Newsgroup Account Settings > the POP account > Copies & Folders: Change 'Place a copy in:' to "Sent" Folder on Local Folders. OK. 4. Try to delete Sent folder on the POP account -> SUCCEEDS, this is correct. 5. Quit, restart. 6. Verify that there is no Sent folder on the POP account -> FAILS, Sent folder has reappeared; this is a BUG. 7. Try to delete Sent folder on the POP account -> FAILS, Sent folder should be deletable; this is a BUG. 8. Verify that 'Place a copy in:' is still set to "Sent" Folder on Local Folders. -> OK, but Sent folder should be deletable then. 9. Change 'Place a copy in:' to "Sent" Folder on the POP account. OK. Change 'Place a copy in:' to "Sent" Folder on Local Folders. OK. 10. Try to delete Sent folder on the POP account -> SUCCEEDS; apparently there was some confusion as to what the 'Place a copy in:' pref was set to? Actual Results: Sent folder appeared after restart at step 6. Sent folder could not be deleted at step 7. Expected Results: Sent folder should have not reappeared after restart at step 6. Should be possible to delete Sent folder at step 7 (well, it shouldn't even exist at that point, but you get the idea...). If I send mail in the state at steps 6-8, the sent message is placed in the correct folder, on Local Folders. Also Local Folders' Sent folder is not deletable at that point, which cannot be correct -- only one Sent folder can be the target when there is only one sending identity. The other special folders seem to follow the same 'logic'.
The problem worsens. Now I also got a junk folder. I don't need it, I don't use this feature. So my pop account has more and more useless folders:-( This bug is not OS dependend. Changing. This bug does not block bug 33235, it just asks for partially the opposite. pi
No longer blocks: 33235
OS: Linux → All
Hardware: PC → All
See bug 118987. I think this is a duplicate of that bug and some of it's other duplicates. But this is a more focused description of the true problem.
*** Bug 118987 has been marked as a duplicate of this bug. ***
I really had a hard time parsing the summary. Hope, this is is nicer. pi
Summary: 'Copies & Folders' settings confused; can't delete, and keep deleted, special folders (Drafts, Templates, Sent) → Cannot permanently delete unused special folders (Drafts, Templates, Sent)
*** This bug has been marked as a duplicate of 133231 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
Reopening. This bug is NEW (the other one UNCONFIRMED) and has probably the correct component. Furthermore, the summary of that other bug is also not correct anymore, since you cannot delete those folders in the first place. Gonna dupe the other way round. pi
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 133231 has been marked as a duplicate of this bug. ***
I've commented about folder problems elsewhere. Didn't know until today that some are "special". I used to use folder renaming (Sent, Inbox) as the way to close out an old box and start a new one, in Netscape 4.x and possibly older Mozillas. In the past 6 months I've noticed that Mozilla somehow keeps track of name changes of special folders, and keeps using the old renamed one. I renamed Trash to Trash01 as I was saving some spam at the time, and "delete" put the deleted mail into Trash01 instead of the newly created Trash. This was reported. I generally make these changes using commandline file commands, btw. Then, renaming the Inbox to (for ex.) In001 and Sent to Sent001 resulted in new mail being put into In001 instead of a new Inbox, even if a new Inbox folder was created. I don't recall if Sent had this problem. I think I copied the folders as Inn001 and Snt001 and then deleted Sent and Inbox so they would be recreated---this was some months ago. Recently I had to do a more drastic renaming of Inbox as the previous changes still made the folder appear or act as Inbox, and I've got two folders that show as Sent, though the older of them is renamed. I haven't seen any variable in the about:config list that shows a pref that sets a value for "Inbox". And the settings for "Sent" don't explain what's going on here. The help discussion of filters says that if a folder that's a target of filtering is renamed, Mozilla somehow keeps track of the renaming and updates the filtering accordingly. How can Mozilla do this if it's not running when a folder name change is made? But it happens. Where are the aliases of folders stored? Evidently not in preferences, and not in the Windows registry or equivalent data structure in other operating systems. The filtering code may be the reason why name changes are so hard to do now. But renaming to close out a folder so a new folder is created is very handy to keep the folder sizes manageable and do mail backups. Perhaps all special folders are susceptible to problems of renaming, deletion, etc. To me, the behavior of recreating a deleted special folder is useful.
I looked at the source code and found only one place where the inboxFolderName was assigned. That's the variable that holds the filename Inbox or terms in other languages for it. I saw no clue as to how a folder of another name could get the use of the Inbox icon and possibly have its name and function confused with the folder (file) called Inbox. It would be nice if someone would look into this. Meanwhile, I'll be looking at some other mail/news sourcecode for answers.
Reassigning to (new) default owner.
Assignee: mscott → sspitzer
Status: REOPENED → NEW
There seems to be a work-around in Bug 110672. These special folders can neither be deleted for POP3 accounts. IMAP accounts do it correctly: when changing the folder settings for the account to have them on Local Folders, the server-side folders disappear from the list.
I confirm that this bug exists and is always reproducible in Mozilla 1.5 on Windows 2000, with POP accounts.
Here's a stack from when PR_Open touches an unwanted Sent mailbox into existence. Making nsPop3IncomingServer::CreateDefaultMailboxes just return w/o touching things fixes this issue (and surely breaks other stuff, but that seems to be where these folders respawn).
Is there any difference to Bug 35310?
(In reply to comment #14) > Is there any difference to Bug 35310? Not that I can tell. This bug, though later, has slightly longer cc list and isn't assigned to a @formerly-netscape.com.tld, in case you dup. Fwiw, commenting out only the bits in nsPop3IncomingServer::CreateDefaultMailboxes that touch the three offending folders, only seems to direct the default copies&folders prefs to Local Folders instead of the expected new account on account creation, and doesn't seem to break much else (in case this bothers someone who builds their own, a lot). In case there's any confusion about the expected results, jglick's bug 35310 comment 2 puts it very succintly. As for properly fixing this, it would seem to require understanding moz mail apps' logic, which I don't :)
(In reply to comment #15) > (In reply to comment #14) > > Is there any difference to Bug 35310? > > Not that I can tell. No, I think it really is. Both bugs are simply asking for the ability to delete extraneous folders that they don't use (Drafts, Templates, etc for every account), and currently those folders are getting recreated upon restart even if you delete them (and all references to them). So yes, jglick's #2 comments describe what *should* happen, but the last part "Otherwise, they can be deleted and shouldn't be recreated" is what is currently untrue. This bug is better documented in the description, tho, so I'd base off this one.
*** Bug 35310 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > There seems to be a work-around in Bug 110672. > > These special folders can neither be deleted for POP3 accounts. > > IMAP accounts do it correctly: when changing the folder settings for the account > to have them on Local Folders, the server-side folders disappear from the list. When using IMAP this "feature" works indeed. Notice that you can just "unsubscribe" a folder when using IMAP. You don't necesseraly have to "delete" the folder from the mailserver. POP fails to work as said above. Is anyone still working on this?
Here's the hack-around that I use, and mentioned in comment 15, i.e. commenting out the offending folders' creation in nsPop3IncomingServer::CreateDefaultMailboxes. Presumably there is a case where that function's original functionality is correct, such as at new account creation (presuming you wanted these folders for a POP account at that time in the first place) -- I haven't been able to tell apart call sites for accidental and purposeful creation of special folders so this is the best I can do, at least for now.
I'm currently having the same problems with Thunderbird 0.7RC. The "special" folders are deletable when the Copies&Folders settings are tweaked, but they are recreated as soon as TB is restarted. Another idea is to add a similar option to "Copies&Folders", for the Trash folder. I don't need a separate Trash folder for each POP account, I want to put all deleted emails in the Trash folder on the Local account.
*** Bug 254705 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > Presumably there is a case where > that function's original functionality is correct, such as at new account > creation (presuming you wanted these folders for a POP account at that time in > the first place) -- I haven't been able to tell apart call sites for accidental > and purposeful creation of special folders so this is the best I can do, at > least for now. Surely it would be best not to create any of these folders unless they are wanted? ie. unless something tries to put something in one. If the folders were only created when used, many useless folders would not be created at startup. Creating them at startup just makes startup slower and creates a whole lot of useless files.
*** Bug 293520 has been marked as a duplicate of this bug. ***
I would like to ask for the same (permission for deleting special folders) for Local Folders. But I also want it to be reversible. Like for example, recreating a Templates folder if I decide I want to use it again and then have it recognized as the official Temaplates folder - with its own special icon and everything. But I think three folders must not be allowed to be deleted: Inbox Sent Trash The exception would be for non-local folders when all mail has been directed to local folders. Maybe Drafts is another exception.
I emphatically confirm this very annoying problem. ITs sad to see that this bug has been reported for some time, but yet no fix has been made, nor a temporary "duct-tape" solution for us to impement until this problem is resolved in a future release. It would benice if there could be a line we can add/delete/modify in the prefs.js to stop this from happening. I also tried this with thunderbird - but same problem. I even tried creating read-only folders with the names Drafts and Drafts.msf, but surprizingly Mozilla deletes the Drafts.msf folder and creates the file Drafts.msf file!
Hey guys, can we get some action on this bug? Thanks. Except for Brak01 and my messages last month, there seems to have been little work on this bug. There's this attachment called the 2-line hackaround, but for end users like us, the code doesn't make much sense. The person whom this bug is assigned to reads "not reading bugmail". I wonder, if so, who will take care of this problem. Please help us. You guys (the coders) are who we depend on. Thanks.
*** Bug 249299 has been marked as a duplicate of this bug. ***
I've just suggested a major redesign of the entire folder system (for Thunderbird 2.0) which would solve this bug. See: http://wiki.mozilla.org/Talk:Thunderbird:2.0_Product_Planning#Major_Usability_Redesign_of_Folders_.26_Threads_.28in_4_Steps.29
In theory, we don't need to create these folders until they're used.
Assignee: sspitzer → bienvenu
other than the inbox and trash, we can (and do) create the other folders lazily...
Attachment #245034 - Flags: superreview?(mscott)
Comment on attachment 245034 [details] [diff] [review] create special folders lazily I was worried about the Junk folder here as we have reports from some users that with new profiles, we aren't creating the junk folder properly. But I see in this patch all we are tweaking is Drafts, Sent, and Trash.
Attachment #245034 - Flags: superreview?(mscott) → superreview+
fixed on trunk and branch
Status: NEW → RESOLVED
Last Resolved: 16 years ago → 13 years ago
Resolution: --- → FIXED
(In reply to comment #31) > we have reports from some users > that with new profiles, we aren't creating the junk folder properly. Bug 351545?
for QA/testing, the areas to try are creating new pop3 accounts that don't use the global inbox, and making sure that special folders like sent/drafts/templates are created the first time you try to save as draft/template, or send a message. Also, make sure that if you configure TB not to use a special folder in an account, e.g., set the sent folder to an other account, make sure you can delete the sent folder, and that it doesn't get recreated on startup. (You may need to shutdown and restart before you can actually delete the sent folder; I'm not sure)
Having commented on folder issues 3.5 years ago, I'd like to follow up with the opinion that unused folders are probably not much of a burden to a user and her system, The big concern to me is the ability to rename a folder for backup purposes so Mozilla, Seamonkey or Thunderbird recreates a new folder with a standard name and uses it. The program should not keep track of the renaming and try to use the old folders that a user doesn't want to be active anymore. I don't know what kinds of backup strategies others use, but if I receive enough mail in Nov and Dec 2006 that I want to make a backup folder of my Inbox, I'd like to be able to rename it 2006NovDecInbox, for example, and have Seamonkey (or Thunderbird) make a new Inbox. All the standard folders that don't exist might as well be created at program startup, and then be the ones used for their expected purposes.
I think some sort of explicit backup/archive command would be a better solution...
(In reply to comment #36) > Having commented on folder issues 3.5 years ago, I'd like to follow up with > the opinion that unused folders are probably not much of a burden to a user Not for you maybe. But YMMV. > The big concern to me is the ability to rename a folder for backup > purposes so Mozilla, Seamonkey or Thunderbird recreates a new folder with a > standard name and uses it. Here again YMMV: I think there are better ways to backup. And it is not that much of a problem to create a new folder, and copy/move all the mails there. Im not against implementing this, cos everything that improves a pgroam is good. But I dont think this is the main issue with deleting special folders. jm2c
I suspect that this caused bug 365113
This shows as resolved but it is NOT RESOLVED. Thunderbird 2 Beta 1 latest nightly build 12.27.06 No way to delete Drafts folder. User can right-click no a created subfolder - the option to delete is there. User can right-click on a drafts folder - no option to delete is there. @ #38: I think that we should be able to delete special folders if we wish. Sometimes the maintainers of a program go overboard in not letting the users do things that may be "harmful." I say please let us in this case - because it is USEFUL for those with many inboxes to be able to see more items on the screen. Thanks!
You first have to tell Thunderbird not to use that folder: in Account Settings under Copies & Folders make sure that no account uses the folder that you want to delete (by telling it to use the Drafts folder in another account, such as Local Folders). Once you have done that the Delete option appears. I noted that if you delete the folder in TB2.0 and go back to TB1.5, TB1.5 recreates the folder. If you then go to TB2.0 the option is no longer there, although no account uses it. The work-around that I found was to tell Thunderbird to use the folder again and click OK and then again to tell Thunderbird not to use the folder (again) and the Delete option reappears. This whole thing is perhaps not that obvious to everyone. Maybe the Delete option should always be there but when the folder is still "in use" Thunderbird might show a message.
(In reply to comment #34) > for QA/testing, the areas to try are creating new pop3 accounts that don't > use the global inbox, and making sure that special folders like > sent/drafts/templates are created the first time you try to save as > draft/template, or send a message. This seems to be working as expected. > Also, make sure that if you configure TB not to use a special folder in an > account, e.g., set the sent folder to an other account, make sure you can > delete the sent folder, and that it doesn't get recreated on startup. (You > may need to shutdown and restart before you can actually delete the sent > folder; I'm not sure) You do not need to shut down in order to delete after making a change, altho the icon of the folder doesn't change until restart, nor does its order in the folder tree. There is some confusion due to the fact that these folders are all identity-specific. If I have an account with a primary identity and a secondary, and I edit the secondary to tell it to use an alternate Drafts folder, I can then immediately delete the existing Drafts folder, even tho the primary identity still has it "in use". But if I don't delete, and then restart, Drafts is still a special folder and again doesn't offer the delete option, until I change another identity to point elsewhere. As far as these folders are concerned, being able to delete a folder when one identity has it assigned really isn't a problem; rather: Since we have the "lazy" creation of these folders anyway, why prevent the deletion or renaming of these folders at *any* time? But the other part of the problem -- something I've noted before -- is that treating identity-specific options as if they're part of the account is confusing. What's the best option here - allow the user to go forward and later discover that the Drafts folder he thought was deleted is back, and not deletable, *again*? - prompt? "This same folder is in use by multiple identities; apply change for all?" (Probably a better phrasing could be found.) - just automatically redirect every instance of <account>|Drafts to <Local Folder>|Drafts? I don't think any of those options are good; and this problem pertains to all the identity-specific settings, such as "Compose in HTML". In the specific case of folders, having them identity-specific is cumbersome and useful only to a small subset of users. It would be great if these settings could somehow be account-specific unless the user specifically changed a setting somewhere.
See also bug 366609.
Looks like patch for this bug caused Bug 368064
You need to log in before you can comment on or make changes to this bug.