617457 - IMAP Special Folders (i.e., "Trash") get created recursively when using Personal Namespace and manual folder selection

Status: RESOLVED DUPLICATE of bug 491424

(MailNews Core :: Networking: IMAP, defect)

Description

[Jon Grossart]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6

I am using a webhost for my business domain.  However, I began noticing that when I select the Trash folder, it creates a new "phantom" folder.  My host uses the personal namespace "INBOX.".  TB correctly uses that namespace and automatically selects the special folders (Trash, Sent Mail, Drafts, etc).

However, if I ever change the default directory for the Trash, it creates a recursive Trash directory on the server, even though it still uses the trash correctly.

If I list the folders on the server, it shows up as:

. list "" "*"
* LIST (\HasChildren) "." "INBOX"
* LIST (\HasNoChildren) "." "INBOX.Trash"

Once I select the Trash folder via the UI, it then creates the following folder:
* LIST (\HasNoChildren) "." "INBOX.INBOX.Trash".

The only way to prevent this folder from being created is to never change the default folders.


Reproducible: Always

Steps to Reproduce:
1. create an IMAP account on my host (defaults to "INBOX." namespace)
2. special folders work correctly
3. change the Trash folder in the UI under Account Setting->{account}->Server Settings->Server Settings-> trash folder selection to use INBOX->Trash
4. restart 
Actual Results:  
Trash still works, but an INBOX.INBOX.Trash folder is also created.

From a account preferences perspective, mail.server.server4.trash_folder_name gets created with value INBOX/Trash.

If I set the preference key back to default value using about:config, the trash folder works correctly.  INBOX.INBOX.Trash disappears from the folder list, but still remains on the server.  If I delete the INBOX.INBOX.Trash folder from the server (which I can only do via telnet into dovecot), it does not get recreated.

Expected Results:  
Trash works, no extra folders created.  User is able to select even the original folder from the drop down list without unneeded user preferences being created or new folders being created incorrectly.

Should the user preference not be created if selecting the same folder as the default folder?  Should the perference be stored as "INBOX.Trash" instead of "INBOX/Trash", or even just "Trash" since the INBOX part is already part of the namespace?

Comment 1

[Jon Grossart]

Attachment: IMAP logs from Thunderbird for affected account.

Comment 2

[WADA:World Anti-bad-Duping Agency]

dup o bug 491424?

Comment 3

[Ludovic Hirlimann [:Usul]]

(In reply to comment #2)
> dup o bug 491424?

Jon do you agree ?

Comment 4

[Jon Grossart]

Yes, that would seem like a dupe...and here I though I found something new (even after searching the bug database).

Although, this bug has then been around for 1.5 years with no real progress.  It seems like an important bug that users can't select a Trash folder (and other special folders?) manually without creating unwanted consequences.

Comment 5

[Jon Grossart]

Actaully, looking through the namespace bugs, it seems that TB IMAP namespace support is in very sorry shape.

Comment 6

[WADA:World Anti-bad-Duping Agency]

Simplest solution: Hide trash selection UI, if server uses namespace.
Since user has to type string by himself as before if UI is hidden, string like "Inbox/Trash" in mail.server.serverX.trash_folder_name is user error when namespace of "Inbox" is used, because Tb's design/implementation was Trash-folder-for-Tb==<namespace>+<trash_folder_name> since initial of trash_folder_name support. And, the design/implementation is still kept.
So, bug of Tb can not exist, if UI is hidden :-)

> (and other special folders?)

No, trash only issue. As "full path of folder" is used for Copies&Folders and Junk Settings, namespace is not relevant to imap folder access.

"full path of folder" in trash_folder_name is a solution of this bug. However, it breaks compatibility with former versions which don't support "trash folder selection UI".
New real_trash_folder_name for full path may be a solution. It's similar to .hostname/.realhostname and .realuserName/.userName in mail.server.serverX settings. It's simirar to .directory-rel/.directory also.