Open Bug 119630 Opened 23 years ago Updated 2 years ago

On RENAME failed error when moving to trash, show alert

Categories

(MailNews Core :: Networking: IMAP, defect)

defect

Tracking

(Not tracked)

People

(Reporter: ian, Unassigned)

References

Details

(Whiteboard: [patchlove] see suggested fix in comments 8 and 10)

Attachments

(1 file, 1 obsolete file)

IMAP Server: mail.damowmow.com Username: m2079682 Password: mozilla e-mail address: test@damowmow.com I can't delete folders that I create on this IMAP server. I get the error "RENAME failed: Can't create mailbox node /mnt/looney/hardangervidda/m1836634/mail/Trash/: File exists." Note: In this error message, the mailbox name is different than in the details I gave above, because this is my real mailbox and the one above is my testing mailbox. :-)
Duplicate of bug 115988 which has been resolved.
That bug is marked "WONTFIX". That is not an acceptable resolution for this bug. I'm not a beginner user and I would have no idea how to solve this problem (I still have no idea even after reading that bug). No other mail program I have used has this problem.
Hi, Ian, glad to hear the feedback. Can you try to see if this bug can still be reproduced after you clear the setting as followings: 1. Select Menu 'Edit'->'Mail & Newsgroup Account Settings...' 2. In the opened 'Mail & Newsgroup Account Settings' dialog, select your account and then select 'Server settings' 3. In the right part of the interface, click the 'Advanced...' button 4. In the 'Advanced IMAP Server Settings' dialog, clear the 'Server supports folders that contain sub-folders and messages' checkbox to make it unselected.
That does indeed fix it. Is there any way we could automatically detect that this is the problem and suggest that the pref be toggled? Or is there maybe a way to query the server to see if it supports that?
Oh, glad to hear that you have solved the problem, Ian. Thank you for your suggestion, but sorry for that there is not appropriate way to query the server to see if it supports that now, so mozilla put it into preference. I'll try to see if the default setting can be changed to support that feture more widely.
How about doing this to delete folders (when the "Server supports folders that contain sub-folders and messages" checkbox is checked): Try to move the folder as we do now. If that fails, then look at the error. If it's "RENAME failed" then, assuming this has not happened before, offer the following to the user: ::::::::::::::::::::::::::::::::::::::::::::::::::::: | | | .___ The server cannot move this folder to the | | V__/ trash folder. Mozilla has determined that | | this may be because of a limitation of the | | server software. Would you like to | | permanently delete the "Foo bar" folder | | instead? | | | | [X] Server does not support folders that | | contain sub-folders. | | | | ( Permanently Delete Folder ) (( Cancel )) | | | +---------------------------------------------------+ | > Error message | +---------------------------------------------------+ The disclosure widget at the bottom would open to show the following: . . : ( Permanently Delete Folder ) (( Cancel )) : | | +---------------------------------------------------+ | v Error message | | | | The error message from the server was: | | | | RENAME failed: Can't create mailbox node | | /mnt/looney/hardangervidda/m1836634/mail/Trash/: | | File exists. | | | +---------------------------------------------------+ cc'ing jglick and mpt for advice.
You cannae have a disclosure triangle at the bottom of an alert or dialog, because once it's open (and its open status should be remembered between invocations), the closing buttons are no longer at the edge, which is bad. The way around that is to put the buttons vertically in the top right corner, but that isn't advisable unless the alert or dialog is frequent (e.g. the cookie alert), and this one won't be. I tried adding the `Delete Folder' thing, but that combined with the screeds of text just made the alert too complicated. Here's what I ended up with: ,------------------------------------------------. |::::::::::::::::::::::::::::::::::::::::::::::::| |------------------------------------------------| | _ The folder "Foopy" could not be moved to | \ | (x) to the Trash, because the mail server | > <label> | " reported an error. | / | | | If you have this problem regularly, try | \ | turning off "Folders can contain other | | | folders" for this server in the Account | | | Manager. | \ | | / <description> | RENAME failed: Can't create mailbox node | | | /mnt/looney/hardangervidda/m1836634/mail | | | /Trash/: File exists | / | | | (( OK )) | `------------------------------------------------'
Ok, how about just this: ::::::::::::::::::::::::::::::::::::::::::::::::::::: | | | .___ The server cannot move this folder to the | | V__/ trash folder. Mozilla has determined that | | this may be because of a limitation of the | | server software. Would you like to | | permanently delete the "Foo bar" folder | | instead? | | | | RENAME failed: Can't create mailbox node | | /mnt/looney/hardangervidda/m1836634/mail | | /Trash/: File exists. | | | | [X] Server does not support folders that | | contain sub-folders. | | | | ( Permanently Delete Folder ) (( Cancel )) | | | +---------------------------------------------------+
Yah, that's what I had before realizing it was too complicated. :-)
Actually, change the top bit to the following, to reduce the sentence count: | .___ The server cannot move this folder to the | | V__/ trash folder, probably because of a | | limitation of the server software. Would | | you like to permanently delete the "Foo | | bar" folder instead? |
mpt: Your dialog is not simpler, since it requires the user to perform about nine extra clicks to get the same result. (Count them.) It also requires that the user either write down the steps or be very good at memorising instructions.
<mpt> it is so simpler <Hixie> One click and one extra sentence is more complicated than 10 clicks are memorising the steps required? What on earth makes you think that? <mpt> I'm balancing the probability that users will read an alert of a given size against the probability that they'll lose their folder completely without wanting to. <Hixie> They won't read the alert. They'll read the button texts. One is clearly marked Permanently Delete Folder. In addition, I'm *assuming* they won't read the text: that's why the checkbox is initially checked. With your proposal, the user will be none the wiser, and the folder will still be there.
<mpt> timeless: if I had a button labelled `Permanently Delete Folder' <mpt> timeless: babelfish tells me the Spanish localization of that would be `Permanentemente Carpeta de la Cancelación'. Does that sound right? <timeless> I'd shoot you for the English wording already :-)
I don't care what the wording is, it's the functionality I'm worried about.
i'll offer two strings. i'm not warranting them or anything :) erase folder. borre la carpeta. i have a few reasons for erase. one is that it appears to translate better into spanish (this is about the worst possible reason to pick a word). another is that by choosing it i set the verb apart from the original action which these days implies going to a trash folder. in days of old there were programs to unerase (ms even branded that flavor) but these days i think your average user will accept that you can't undo an erasure.
I also think 'Undo' function is important. But some kind server doesn't support 'Undo'(move to Trash and move it back again), so we must supply a function(truely delete it) to complete the user's wish. Otherwise, it would ba annoying that the created folders can't be deleted.
I agree with Henry. timeless: what we call the button in English has absolutely no bearing on what the button is called in other languages.
1. henry's comment is irrelevant. 2. mpt asked me for a spanish translation, now he has one. you are certainly under no obligation to use it or its English pair. I think actually that 'permanently erase folder' sounds better than 'permanently delete folder'. but i can't explain why.
umm, even if WONTFIX is an "unexaptable resolution" as per comment #3, this _is_ a duplicate of bug 115988 - shouldn't this be marked as so and the other bug reopened? or at least link the bugs by a comment in 115988 - it's terribly confusing to have to bugzilla bugs for one issue. Also see bug 133748 - is that a dupe of "this"?
Summary: Can't delete folders on dreamhost.com mail servers (RENAME failed) → On RENAME failed error when moving to trash, show alert
Whiteboard: see comments 6 and 10
*** Bug 133748 has been marked as a duplicate of this bug. ***
I see the same problem with an IMAP server that runs IMAP4rev1 v12.264. The problem is fixed by performing the steps in comment 3, BUT the folders come back if I shut down mozilla and reopen mail. It should also be noted that the folders that mozilla finds have already been removed though the webmail interface for this IMAP server. So when mozilla removes these folders it tells me: The current command did not succeed. The mail server responded: DELETE failed: Can't delete mailbox Mozilla: no such mailbox. The deletion of the folder in mozilla still succeeds, but as I said; it comes back if I close and reopen mozilla.
*** Bug 100748 has been marked as a duplicate of this bug. ***
We have fix on bug 120485 recently. Reporter, does bug 120485 solution fix this problem as well? Can you try again?
still a problem with 2002070915. (how recently was it fixed?)
Seems to work for me... (1.1a on linux (2002061108))
Attached patch patch for discussion (obsolete) — Splinter Review
This patch is for discussion, including the interface. Please review.
This is the alert window picture using the patch ( attachment #92690 [details] [diff] [review] ). It's similiar to comment #8 with a little change to make it more clear.
This bug really exists on the server that doesn't support folders that can contain sub-folders and messages at the same time, such as UW IMAP server that support IMAP 4.
Jennifer, Henry needs your help in finalizing the UI for this. There are a lot of extraneous comments in here, but I'll try to restate the problem. There's an Advanced IMAP server setting called "Server supports folders that contain sub-folders and messages" which is (and should be) on by default. If this setting is set, but the server DOES NOT support folders that contain sub-folders and messages, attempts to delete imap folders will fail with a message from the server. When a delete fails, we'd like to tell the user that it might be because of this setting, and either direct them to the Advanced IMAP server settings UI to fix it, or let them fix it right in the alert dialog we pop up. Re Henry's question about the code: "the patch can permanently delete the folder successfully but it doesn't refresh the pane (tree view) after the delete". This works when the user has the dual-use pref set correctly, so I'd go look at why that works and your patch does not. I'm not sure what it does to get that to work.
Thx, David. Call stack: nsImapProtocol::OnDeleteFolder -> nsImapProtocol::FolderDeleted -> nsImapIncomingServer::OnlineFolderDelete (where just return NS_OK) Since this bug also exist on other platforms, change the platform and OS attributes.
OS: Linux → All
Hardware: PC → All
This one is hard because we are trying to do several separate things with this dialog: 1. Let the user know there was an error 2. Let them know why the error occured 3. Provide a suggestion for what they might try to fix the problem permanently 4. Offer to permanently delete the folder for them 5. Offer to fix the potential problem for them Usually you'd do 1, 2, 3, and 4 OR 1, 2, 3 and 5, but not all of them. ------------------------------------ If we did try to combine all items, i'd suggest: <ProductName> was unable to move this folder to the Trash. This may be because of a server limitation. If you continue to have this problem, try turning off "Server supports folders that can contain sub-folders and messages" in the advanced IMAP settings for this account. Uncheck the box below to do this now. Would you like <ProductName> to permanently delete this folder now? [X] Server supports folder that can contain sub-folders and messages Delete/Cancel ------------------------------------- If that seems too complicated, i'd suggest: <ProductName> was unable to move this folder to the Trash. This may be because of a server limitation. If you continue to have this problem, try turning off "Server supports folders that can contain sub-folders and messages" in the advanced IMAP settings for this account. Would you like <ProductName> to permanently delete this folder now? Delete/Cancel
Taking. :-) Add mscott to CC list.
Assignee: mscott → Henry.Jia
*** Bug 139477 has been marked as a duplicate of this bug. ***
Keywords: interop
QA Contact: huang → meehansqa
Whiteboard: see comments 6 and 10 → see suggested fix in comments 8 and 10
Product: MailNews → Core
related to bug 117664? Deleted IMAP folders are still visible
Keywords: qawanted
QA Contact: meehansqa → networking.imap
Whiteboard: see suggested fix in comments 8 and 10 → [patchlove] see suggested fix in comments 8 and 10
Product: Core → MailNews Core
Assignee: Henry.Jia → nobody
Comment on attachment 92690 [details] [diff] [review] patch for discussion Patch has bitrotted: $ patch -p0 --dry-run < ~/Desktop/bz119630.diff patching file jar.mn Hunk #1 FAILED at 169. Hunk #2 FAILED at 236. 2 out of 2 hunks FAILED -- saving rejects to file jar.mn.rej patching file imap/public/nsIImapServerSink.idl Hunk #1 FAILED at 65. Hunk #2 FAILED at 77. 2 out of 2 hunks FAILED -- saving rejects to file imap/public/nsIImapServerSink.idl.rej patching file imap/src/nsImapIncomingServer.cpp Hunk #1 FAILED at 93. Hunk #2 FAILED at 2189. 2 out of 2 hunks FAILED -- saving rejects to file imap/src/nsImapIncomingServer.cpp.rej patching file imap/src/nsImapProtocol.cpp Hunk #1 succeeded at 489 (offset 167 lines). Hunk #2 FAILED at 4344. Hunk #3 succeeded at 6827 with fuzz 1 (offset 1017 lines). 1 out of 3 hunks FAILED -- saving rejects to file imap/src/nsImapProtocol.cpp.rej patching file imap/src/nsImapProtocol.h Hunk #1 FAILED at 598. 1 out of 1 hunk FAILED -- saving rejects to file imap/src/nsImapProtocol.h.rej
Attachment #92690 - Attachment is obsolete: true
Henry, any chance of a new patch?
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: