195142 - Canceling a move to trash permanently deletes mailbox

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect)

Description

[Waldemar Horwat]

Turn off "Confirm when moving folders to the Trash" in the preferences.

Create a mail folder with named F in the mail account.
Create a subfolder Alpha inside F and move some mail there.
Create a subfolder Beta inside F and move some mail there.
Create a mail filter rule that targets Alpha.

Now move F into the trash (which I did by accident a while back).  The browser
comes back with the dialog:
"Deleting the folder 'Alpha' will disable its associated filter(s).  Are you
sure you want to delete the folder?"

Click Cancel.  F and Beta will be moved into the trash.  Alpha, and all of its
contained mail will be gone and unrecoverable.  This is a major data loss.

Had I clicked OK, F, Alpha, and Beta would have been moved into the trash, and I
would have been able to look at their messages but unable to move them out of
there (a folder already exists alert would come up even though none is visible)
unless I went inside Library/Mozilla/Profiles/waldemar/<my salt>/Mail and
deleted an extraneous copy of the F folder.

Comment 1

[David :Bienvenu]

not a mail database (.msf file) issue.

these are presumably local mail folders and not imap folders.

Comment 2

[Waldemar Horwat]

This is a POP mailbox.

Comment 3

[Asa Dotzler [:asa]]

not likely to happen in time for 1.3

Comment 4

[Samir Gehani]

adt: nsbeta1-

Comment 5

[Asa Dotzler [:asa]]

I'm going to look around bugzilla. Waldemar, is this 100% reproducible? Are
those the exact conditions required to reproduce. 

Comment 6

[Waldemar Horwat]

Yes, it's 100% reproducible using today's trunk Mozilla build and the steps
provided in the initial bug report.  I lost several mailboxes full of mail due
to this bug.

Comment 7

[Andrew Hagen]

Is this a regression? Could someone please check to see if it occurs on 1.2,
1.1, etc? TIA.

Comment 8

[David :Bienvenu]

I tried this several times and didn't have a problem. Either there's something
special about Waldemar's setup, or I didn't quite follow the steps correctly
(though I think I did). Perhaps someone else could try this. Was the trash
folder on the same local account?

Comment 9

[Waldemar Horwat]

Yes, the trash was on the same local account.  I can reproduce this bug even
with a brand new profile.

Are you using POP mail?  I haven't tried this with IMAP.

Comment 10

[David :Bienvenu]

Yes, my tests were with local folders.

Comment 11

[Waldemar Horwat]

Do you mean folders in the "Local Folders" folder, or folders stored locally on
the machine but part of a POP account?  I was using the latter.  What machine/os
are you using?  What did you do to try to reproduce this bug and what happened?

Comment 12

[Andrew Schultz]

I am able to reproduce this consistently using Linux trunk build 20030515 with
the steps in comment 0.  It also occurs with release builds back to 1.0.

It occurs with POP folders as well as Local folders.

Comment 13

[David :Bienvenu]

I tried this on Linux as well - it worked fine. I'll try it under Purify, and
look at the code to see if maybe there's some sort of uninitialized variable.

Comment 14

[Andrew Schultz]

Attachment: patch

there are two bugs here.  this fixes the dataloss

1. the |copyStatus| for Alpha (which failed because the user hit cancel) is
clobbered by the |copyStatus| for Beta which succeeds.	This patch fixes this
by bailing from the subfolder loop immeadiately when CopyFolderLocal fails.

2. the folder F is still "copied" to trash (it happens before the
filter/confirmation dialog).  if the filter had been on folder Beta, Alpha
would be "copied" to trash.  The trash folder is not updated when this happens.
 You have to open a new window (double-click on trash).

Comment 15

[David :Bienvenu]

Comment on attachment 123550 [details] [diff] [review]
patch

sr=bienvenu - that makes sense.  In theory, we should be pre-flighting the
whole thing correctly, but the fix looks fine to me.

Comment 16

[(not reading, please use [e-mail] instead)]

Comment on attachment 123550 [details] [diff] [review]
patch

r/a=sspitzer, I'll land this.

Comment 17

[(not reading, please use [e-mail] instead)]

whoops, I forgot to land this.

I'll land today.

Comment 18

[Asa Dotzler [:asa]]

Yeah, we want this for 1.4.

Comment 19

[(not reading, please use [e-mail] instead)]

fixed landed on trunk and branch, but we need spin off bugs on the other issues.

Comment 20

[Ninoschka Baca]

Trunk build 2003-06-03: WinMe, Mac 10.1.5, Linux RH 8 - ok.
Branch build 2003-03-03: WinMe, Mac 10.1.5, Linux RH 8 - ok.
Verified Fixed.

Tests performed:
1st Scenario
a. Created a top level folder F
b. Created two subfolders for "F" (alpha, beta)
c. Created filter for alpha
d. Drag-n-dropped folder F to the trash folder

Actual Results: Responded Yes to move the "F" folder to trash, then Canceled the
next dialog which warns that the filter for alpha will be disabled. The current
window shows no change in the folder "F" hierarchy. 

Need to log bug for this issue: Double click so it appears in a new window. The
folder "F" directory structure is there with alpha and beta as subfolders but
flder "F" is also in the Trash folder which is a bug.
Trash
  F

F
 alpha
 beta

Scenario 2
a. Created a top level folder G
b. Created two subfolders for "F" (alpha2, beta2)
c. Created filter for beta2
d. Drag-n-dropped folder G to the trash folder

Responded Yes to move the "G" folder to trash, then Canceled the next dialog
which warns that the filter for beta2 will be disabled. The current window shows
no change in the folder "G" hierarchy. 

Need to log bug for this issue: Double click so it appears in a new window. The
folder "G" directory structure is there with alpha2 and beta2 as subfolders but
flder "G" and alpha2 are also in the Trash folder which is a bug.

Are there any other issues that need to be logged?

Comment 21

[Asa Dotzler [:asa]]

mozilla1.4 shipped. unsetting blocking1.4 request.