User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041002 Firefox/0.10.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041002 Firefox/0.10.1 I created a new IMAP folder, the tried to delete it and received an error message: 'Alert: The current command did not succeed. The mail server responded: RENAME failed: Can't create mailbox node /home/arcticfo//mail/Trash/: File exists. Looks like Thunderbird is trying to create a Trash folder, but one already exists. Reproducible: Always Steps to Reproduce: 1. Create new folder on IMAP account 2. Delete that folder Actual Results: Above error message shown, folder not deleted Expected Results: Folder is moved to Trash
Sorry, If you cannot reproduce this problem on an IMAP server of your own, I would be willing to open an account on my server and give access to the developers so they can test my server. By email.
This is a limitation of your IMAP server. It cannot have folders that can contain both folders and messages. So when you move a folder to trash, it always fails. Select "remove immediately" in the server settings and you can remove the folder.
Or, better, you should go into the client advanced imap server settings for your server and uncheck the box that says "server supports folders that can contain...". Your server does *not* support folders like that.
Thanks - amending bug title. It would seem, then, that the way to fix this would be to have the account automatically fall back to as if "Server supports folders that contain sub-folders and messages" were set to false when creating the folder fails. I've filed bug #263098 (enhancement) for this.
>amending bug title Actually your server probably supports folders containing folders. What it does not support is folders containing both folders and messages. When you create a folder, you indicate if it is a folder for folders or a folder for messages. The Trash folder was created as a folder for messages, so you can drop messages into the Trash, but not folders. If this seems strange, here is how it is implemented: Messages are stored in a file. There is one file for each folder, named like that folder. So there is a file named INBOX, one named Trash, etc. Each "folder that can contain only messages" corresponds to one such file. "Folders that can contain folders" are implemented as a directory. Such a directory can hold "folders that can contain only messages" (files) or more subdirectories. So there can be multiple levels of folders, but once there is a folder with messages it is a file, and thus cannot hold more subfolders. (because on Unix, and also on Windows, there cannot be a file and a directory with the same name) Of course it is an implementation mistake. Folders should have been implemented all as directories, with some dummy file (e.g. "mbox") at the lowest level to hold any messages, and still allowing further subfolders at the same point.
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.