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: