Closed
Bug 389898
Opened 17 years ago
Closed 17 years ago
IMAP mail lost when filtered to local folders
Categories
(MailNews Core :: Filters, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: base12, Assigned: Bienvenu)
Details
(Keywords: dataloss, regression)
Attachments
(2 files, 1 obsolete file)
(deleted),
patch
|
mscott
:
superreview+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
mscott
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007072702 SeaMonkey/2.0a1pre Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007072702 SeaMonkey/2.0a1pre
I'm noticing that IMAP mails are being lost when filtered to local folders. The filter log shows that an attempt was made to move the message, but either no message appears in the local folder, or a blank entry appears in the local folder. This began with the 20070727 nightly build. When I manually move e-mails from IMAP to local folders, I don't seem to lose them. IMAP messages filtered to another IMAP folder seem to get moved properly.
Reproducible: Always
Steps to Reproduce:
1.Set a filter to move IMAP e-mails to a local folder
2.
3.
Actual Results:
Filtered e-mails are removed from IMAP inbox, but do not get placed in local folder specified in filter rule.
Expected Results:
Filtered e-mails should be removed from IMAP inbox, and be placed in the local folder specified in filter rule.
Here's a section of the filter log:
Applied filter "BIC-L@LISTSERV.ND.EDU" to message from Xxx Xxy <xxx@ND.EDU> - Pendragon stats - continued. at 7/27/2007 4:01:03 PM moved message id = 46AA4EFF.4080901@nd.edu to mailbox://nobody@Local%20Folders/BIC-L
Applied filter "BIC-L@LISTSERV.ND.EDU" to message from Xxx Xxy <xxx@ND.EDU> - Pendragon stats - continued. at 7/27/2007 4:02:06 PM moved message id = 46AA4F3E.1030704@nd.edu to mailbox://nobody@Local%20Folders/BIC-L
Applied filter "BIC-L@LISTSERV.ND.EDU" to message from Xxx Xxy <xxx@ND.EDU> - Pendragon stats - continued. at 7/27/2007 4:02:14 PM moved message id = 46AA4F46.7080803@nd.edu to mailbox://nobody@Local%20Folders/BIC-L
And here's what was appended to the local folder file:
From - Fri Jul 27 16:10:01 2007
X-Mozilla-Status: 0000
X-Mozilla-Status2: 00000000
From - Fri Jul 27 16:10:01 2007
X-Mozilla-Status: 0000
X-Mozilla-Status2: 00000000
From - Fri Jul 27 16:10:01 2007
X-Mozilla-Status: 0000
X-Mozilla-Status2: 00000000
Comment 1•17 years ago
|
||
No need to specify suiterunner in title now that it is default on trunk.
Summary: SuiteRunner IMAP mail lost when filtered to local folders → IMAP mail lost when filtered to local folders
Comment 2•17 years ago
|
||
dogfood problem. also seen thunderbird.
regression range using nightly builds is 2007-07-25 ... 2007-07-26. possibly caused by one of these http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2Fmailnews%2F&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-07-25+04%3A00%3A00&maxdate=2007-07-26+06%3A00%3A00&cvsroot=%2Fcvsroot
perhaps caused crashes noted in Bug 391252 and Bug 391357
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: dataloss,
regression
Version: unspecified → Trunk
Assignee | ||
Comment 3•17 years ago
|
||
taking
Assignee: mail → nobody
Component: MailNews: Main Mail Window → MailNews: Filters
Product: Mozilla Application Suite → Core
QA Contact: filters
Assignee | ||
Comment 4•17 years ago
|
||
might be networking: imap but I'll put it at filters.
cc'ing Nick, since if this really is a regression from the imap changes, it might be affecting him as well.
Assignee | ||
Comment 5•17 years ago
|
||
taking - I'll figure this out this afternoon
Assignee: nobody → bienvenu
Assignee | ||
Comment 6•17 years ago
|
||
the problem as I see it, so far is that in nsImapService::FetchMessage, we create a channel:
rv = NewChannel(url, getter_AddRefs(channel));
and call
rv = channel->AsyncOpen(streamListener, aCtxt);
but no one is holding a reference to the channel, so it immediately gets deleted when the comptr goes out of scope.
Assignee | ||
Comment 7•17 years ago
|
||
one more piece of data - in the filter case, there's no load group (I bet that's true in Nick's case as well). Normally, the load group holds onto the request/channel, keeping it alive.
Assignee | ||
Comment 8•17 years ago
|
||
and the reason there's no load group is that there's no msgWindow associated with the operation. For some background operations, we don't have a msgWindow because we don't want the user bothered with things like network errors and password prompts, e.g., for the background check for new mail.
So, we could require a msgWindow, and have a different way of indicating that an operation shouldn't prompt/block, though I hate to require a msgWindow/docshell.
Comment 9•17 years ago
|
||
(In reply to comment #8)
> and the reason there's no load group is that there's no msgWindow associated
> with the operation.
David, does this fact correlate to my crash Bug 391357?
Assignee | ||
Comment 10•17 years ago
|
||
I verified that the load group does get destroyed, with the mock channel destructor on the stack, so I'm pretty sure this isn't introducing a cycle. And it fixes the problem.
Attachment #275881 -
Flags: superreview?(mscott)
Assignee | ||
Comment 11•17 years ago
|
||
need to do this for fetching a mime part as well (which wasn't setting the channel at all)
Attachment #275881 -
Attachment is obsolete: true
Attachment #275900 -
Flags: superreview?(mscott)
Attachment #275881 -
Flags: superreview?(mscott)
Assignee | ||
Comment 12•17 years ago
|
||
er, wasn't setting the loadgroup on the channel at all.
Comment 13•17 years ago
|
||
Comment on attachment 275900 [details] [diff] [review]
fix that includes fix for bug 391402
looks good David.
Attachment #275900 -
Flags: superreview?(mscott) → superreview+
Assignee | ||
Comment 14•17 years ago
|
||
fixed
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 15•17 years ago
|
||
the reason the folder was ending up locked was that we weren't sending an OnStopRequest to the listener in the case where we closed the channel before running the url - I think the same thing would happen if we didn't get to run the url, so I added code to do that. Is it possible that we'll create and destroy/close imap mock channels in other cases, e.g., retries? In which case, this code would be wrong...
The second part of the patch is more important - when I added the first notification, I ended up in nsLocalMailFolder::EndCopy with m_curDstKey set to -1, which made us create a 4GB file. Someone told me they were getting in a situation where that happened, so I hope this fixes that...
Attachment #276221 -
Flags: superreview?(mscott)
Comment 16•17 years ago
|
||
Comment on attachment 276221 [details] [diff] [review]
fix a couple other issues this bug brought up
I'm starting to get nervous about the retry case :). I'll try setting that breakpoint again to see if I can see a retry in the debugger...
Attachment #276221 -
Flags: superreview?(mscott) → superreview+
Assignee | ||
Comment 17•17 years ago
|
||
Try the mozilla.com server - it drops connections all the time :-)
Comment 18•17 years ago
|
||
i can confirm you concerns about retry - fails using 0810 build. our mail server was down and thunderbird hung on the retry.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 19•17 years ago
|
||
Comment on attachment 276221 [details] [diff] [review]
fix a couple other issues this bug brought up
I've checked in the local mail folder part of this patch - I'm a little worried about the OnStopRequest part - it could lead to multiple OnStopRequest notifications, and worse, early OnStopRequest notifications...
Assignee | ||
Comment 20•17 years ago
|
||
I believe this issue is fixed - we should open new bugs for other issues, e.g., the retry issue. If your server was down, we'd never get to the imap filtering code in the first place.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•