Cannot permanently delete unused special folders (Drafts, Templates, Sent)

RESOLVED FIXED

Status

MailNews Core
Backend
RESOLVED FIXED
14 years ago
8 years ago

People

(Reporter: Tuukka Tolvanen (sp3000), Assigned: Bienvenu)

Tracking

({fixed1.8.1.1})

Trunk
fixed1.8.1.1
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

14 years ago
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'.
(Reporter)

Updated

14 years ago
Blocks: 33235

Comment 1

14 years ago
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

Comment 2

14 years ago
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.

Comment 3

14 years ago
*** Bug 118987 has been marked as a duplicate of this bug. ***

Comment 4

14 years ago
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)

Comment 5

14 years ago

*** This bug has been marked as a duplicate of 133231 ***
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE

Comment 6

14 years ago
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 → ---

Comment 7

14 years ago
*** Bug 133231 has been marked as a duplicate of this bug. ***

Comment 8

14 years ago
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.


Comment 9

14 years ago
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.

Comment 10

14 years ago
Reassigning to (new) default owner.
Assignee: mscott → sspitzer
Status: REOPENED → NEW

Comment 11

14 years ago
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.

Comment 12

14 years ago
I confirm that this bug exists and is always reproducible in Mozilla 1.5 on 
Windows 2000, with POP accounts.
(Reporter)

Comment 13

13 years ago
Created attachment 142531 [details]
bt full when touching mailbox

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).

Comment 14

13 years ago
Is there any difference to Bug 35310?
(Reporter)

Comment 15

13 years ago
(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 :)

Comment 16

13 years ago
(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.

Comment 17

13 years ago
*** Bug 35310 has been marked as a duplicate of this bug. ***

Comment 18

13 years ago
(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?
(Reporter)

Comment 19

13 years ago
Created attachment 147246 [details]
2-line hack-around

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.

Comment 20

13 years ago
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. 

Updated

13 years ago
Blocks: 249299
(Reporter)

Comment 21

13 years ago
*** Bug 254705 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

13 years ago
Blocks: 230461

Comment 22

13 years ago
(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.
Product: MailNews → Core

Comment 23

12 years ago
*** Bug 293520 has been marked as a duplicate of this bug. ***

Comment 24

12 years ago
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.

Comment 25

12 years ago
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!

Comment 26

12 years ago
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.

Comment 27

12 years ago
*** Bug 249299 has been marked as a duplicate of this bug. ***

Comment 28

11 years ago
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
(Assignee)

Comment 29

11 years ago
In theory, we don't need to create these folders until they're used.
Assignee: sspitzer → bienvenu
(Assignee)

Comment 30

11 years ago
Created attachment 245034 [details] [diff] [review]
create special folders lazily

other than the inbox and trash, we can (and do) create the other folders lazily...
Attachment #245034 - Flags: superreview?(mscott)

Comment 31

11 years ago
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+
(Assignee)

Comment 32

11 years ago
fixed on trunk and branch
Status: NEW → RESOLVED
Last Resolved: 14 years ago11 years ago
Keywords: fixed1.8.1.1
Resolution: --- → FIXED

Comment 33

11 years ago
(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?
(Assignee)

Comment 34

11 years ago
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)
(Reporter)

Comment 35

11 years ago
*** Bug 230461 has been marked as a duplicate of this bug. ***
No longer blocks: 230461

Comment 36

11 years ago
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.
(Assignee)

Comment 37

11 years ago
I think some sort of explicit backup/archive command would be a better solution...

Comment 38

11 years ago
(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

Comment 39

11 years ago
I suspect that this caused bug 365113

Comment 40

11 years ago
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!

Comment 41

11 years ago
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.

Comment 42

11 years ago
(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.

Updated

10 years ago
Depends on: 365113

Comment 43

10 years ago
See also bug 366609.
Looks like patch for this bug caused Bug 368064

Updated

10 years ago
Depends on: 368064
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.