Closed Bug 762318 Opened 12 years ago Closed 10 years ago

Filter log records blank From, Subject, & Message ID, and default Date & Time(Epoc Time, 1970/01/01 or 1969/12/31) for move action

Categories

(MailNews Core :: Filters, defect)

Product:
MailNews Core
Component:
Filters
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 935934

People

(Reporter: key-mozillabugzilla2939-contact, Unassigned)

References

Details

(Whiteboard: [known workaround : "after classification"])

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0 Build ID: 20120420145725 Steps to reproduce: Looked at filter log. I have filter actions: move starred change priority Actual results: Filter log for move action contains blank/default information for From, Subject, Message ID and default Date/Time. e.g.: <p> Applied filter &quot;[Correct Filter Name]&quot; to message from - at 12/31/1969 4:00:00 PM moved message id = to [Correct message folder] </p> The lines that are entered in the log for the starred and priority change actions appear to have all correct information. This is a change in behavior. On my machine, all moved entries on, or prior to, 4/30/2012 4:16:28 PM properly record all information fields in the filter log. Expected results: The From, Subject, Date, Time, and Message ID should have been correctly obtained from the message being acted upon and entered in the filter log.
What is actual mail in the "Correct message folder" which is corresponds to the "at 12/31/1969 4:00:00 PM moved message id = to [Correct message folder]"? Is there valid filter log entry for the mail which is moved to the "Correct message folder" with Starred and Priority changed? POP3? IMAP? If POP3, do you enable quarantine option? (mailnews.downloadToTempFile=true) Similar filter log is reported also to bug 754301. If POP3 and mailnews.downloadToTempFile=true, do you see problem like bug 754301 in your environment?
I use POP3. Lightning 1.4 is installed (a version of Lightning has been installed in Thunderbird for at least a couple of years). Quarantine option is enabled (mailnews.downloadToTempFile=true) For ALL messages moved by filters (after date/time mentioned above): Everything behaves _exactly_ as it would if the situation was that when the fprintf is executed the strings for From, Subject, & Message ID are "" and the Date/Time is as if it has been converted to a string from a default value. Messages are moved to the correct folder for each filter. The _only_ thing that appears to be wrong is the blank/default data in the filter log. [Correct Filter Name] and [Correct message folder] are the correct filter and folder pairs. I have many filters with "move" actions. All filters that "move" produce the same format results with their respective correct filter name and folder name (i.e. see printf comment above). All filters which are something other than a move action have correctly formatted entries in the log. I have not done a detailed verification that everything single thing is operating correctly, but there is nothing that indicates to me that such verification is needed (e.g. multiple cases where non-move action filters appear to have the correct From, Subject, Date and Time (I have not actually verified any Message IDs)). However, I only have "starred" and "priority change" filters which have matched in the last month+. I do not see any problems similar to bug 754301. No corruption. To cover some of the questions that were asked in bug 754301: My large filter set has been in use for years through many versions of Thunderbird. Test Pilot for Thunderbird 1.3.9 is installed and active.
Component: General → Filters
Product: Thunderbird → MailNews Core
QA Contact: general → filters
do you still see your problem when using version 13?
(In reply to Wayne Mery (:wsmwk) from comment #3) > do you still see your problem when using version 13? Yes, with version 13.0.1.
Adding 1970/01/01 & 1969/12/31 to bug summary for ease of search.
Summary: Filter log records blank From, Subject, & Message ID, and default Date & Time for move action → Filter log records blank From, Subject, & Message ID, and default Date & Time(Epoc Time, 1970/01/01 or 1969/12/31) for move action
No longer blocks: 769511
Thunderbird 13.0.1 07/10/2012 : All of the following came from the same sender; however, they are addresses to three of my email addresses using the local inbox. I always mark two as read and then move them to the local trash folder. The third I move to a folder for emails from BJs for further review. Strange how some dates in log were valid and some not. The header data from BJs should be consistent. ______________________________________From Log_________________________________________ Applied filter "BJs miscsave" to message from "BJ's Member Services" <BJs_MemberServices@email.bjs.com> - FREE Shipping on ASUS at 7/10/2012 8:33:38 AM marked as read Applied filter "BJs miscsave" to message from - at 12/31/1969 7:00:00 PM moved message id = to mailbox://nobody@Local%20Folders/Trash Applied filter "BJs membership expired 02/29/2012 8/30/2012" to message from - at 12/31/1969 7:00:00 PM moved message id = to mailbox://nobody@Local%20Folders/Business/BJs Applied filter "BJs OZ" to message from "BJ's Member Services" <BJs_MemberServices@email.bjs.com> - FREE Shipping on ASUS at 7/10/2012 12:59:47 PM marked as read Applied filter "BJs OZ" to message from - at 12/31/1969 7:00:00 PM moved message id = to mailbox://nobody@Local%20Folders/Trash ________________________________________________________________________________________ Hope this helps a little
howdy y'all, please look at the following post for more details. https://bugzilla.mozilla.org/show_bug.cgi?id=769511#c1 relevant info ... - my filter logs show the last valid log entry was 2012-04-24. that is roughly when tb12 came out. - any filter that triggers a move or a copy triggers this problem. filters that do NOT make a new version [via copy or move] do not trigger the problem. - there is more missing or incorrect that just the date. ***** Applied filter "Forums_-_Mozillazine" to message from - at 1969-12-31 6:00:00 PM moved message id = to mailbox://[account-name-removed]/Inbox/Forums/Mozillazine ***** note that the following are wrong or missing data ... = "from -" [missing all data] = "at" [wrong date] = "message id =" [missing all data] btw, i have my filter log file but am _very_ reluctant to provide it here. the email address i use only for this site is continually showing up in spam msgs. take care, lee
I am also seeing this problem with TB 13 and now 14.0. This makes the filter log USELESS as almost all of my emails are sorted into folders, and it is then impossible to identify messages in the log. A workaround is to set the junk score in the filter rule before the move; you will get an entry in the log about setting the junk score that has correct info right before the bogus move message.
Same Problem TB 13 and now 14.0.
Same Problem TB 15. Every Filter log entry has date 12/31/1969 7:00:00 PM. Thanks, V. Ingram
Same Problem TB 15. EVERY Filter log entry has date 12/31/1969 7:00:00 PM. Other information is present except on "Deletes". Thanks, V. Ingram
I noticed I have the same problem starting around 5/3/2012. around the time of thunderbird 12.0.1 problem exists in TB 17.0.2 still. the filter log is basically almost useless currently. all the info I can get is that something was moved using a particular filter rule. no way to tell which filter applied to which message. useless for debugging problems with my filter rules.
(In reply to Raleightom from comment #7) > Thunderbird 13.0.1 07/10/2012 : > > All of the following came from the same sender; however, they are addresses > to three of my email addresses using the local inbox. I always mark two as > read and then move them to the local trash folder. The third I move to a > folder for emails from BJs for further review. > > Strange how some dates in log were valid and some not. The header data from > BJs should be consistent. > ______________________________________From > Log_________________________________________ > Applied filter "BJs miscsave" to message from "BJ's Member Services" > <BJs_MemberServices@email.bjs.com> - FREE Shipping on ASUS at 7/10/2012 > 8:33:38 AM marked as read > > Applied filter "BJs miscsave" to message from - at 12/31/1969 7:00:00 PM > moved message id = to mailbox://nobody@Local%20Folders/Trash > > Applied filter "BJs membership expired 02/29/2012 8/30/2012" to message from > - at 12/31/1969 7:00:00 PM moved message id = to > mailbox://nobody@Local%20Folders/Business/BJs > > Applied filter "BJs OZ" to message from "BJ's Member Services" > <BJs_MemberServices@email.bjs.com> - FREE Shipping on ASUS at 7/10/2012 > 12:59:47 PM marked as read > > Applied filter "BJs OZ" to message from - at 12/31/1969 7:00:00 PM moved > message id = to mailbox://nobody@Local%20Folders/Trash > _____________________________________________________________________________ > ___________ > Hope this helps a little Problem remains 04/29/2013 . . . . Thunderbird 17.0.5
Confirming based on several reports
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hello Ok Therube Thank, I don't to find this bug, my english isn't fluently. This bug is in seamonkey 2.17.1 since "I don't no when". Sincerly Bertrand
I have had the same problems for a long time. All my filtered messages were displayed in the filter log with the same date and time: 01/01/1970 01:00 (My time zone is UTC +01:00) I believe that the starting point for the indicated time is UTC 01/01/1970 0:00. If you see a different time, for example. 12/31/1969 07:00pm, it indicates that you live in the United States, I think. All my existing filters are set up as follows: Apply filter when: Checking Mail or Manually Run -or Apply filter when: Checking Mail The other night I made two new filters to catch spam. The new filters were set up as follows: Apply filter when: Checking Mail (after classification) or Manually Run -or Apply filter when: Checking Mail (after classification) Mails filtered with these two new filters were to my surprise shown in the filter log with the correct date and time. I have since changed some of the other filters to run "(after classification)". Now they also show the correct date and time in the filter log. It appears then, that the filters that are set up with "(after classification)" disabled, shows the incorrect date (01/01/1970) in the filter log, while the filters that are set up with "(after classification)" enabled show the correct date. I hope that this information can be of help. Sincerly Ole Junker
Ole Junker: Bingo!! Your solution worked for me for all my filters. Thanks, Thanks, Thanks. Gratefully, Dick
Yes, it works, but I have to say that I have not found "The Solution". I have found out, and now we know that the filters that are set with "after classification" enabled shows the correct date and time in the filter log. The right solution must be to find out why the filters that are set with "after classification" disabled does not show the correct date and time. I therefore hope that someone can find and correct the bug. It may not be the right solution to filter all mails through Thunderbird's built-in filters for the sole purpose to get proper dating in the filter log. Mails from known senders should be filtered directly into their respective file folders without unnecessary classification. In my opinion. Sincerly Ole
The option to filter "after classification" is greyed out in filters for all my accounts except for local folders. I have multiple accounts each with their own filters, so this is no fix at all for me. Interesting data point, though.
To bug opener and all problem reporters: (Q1) Do you enable Junk Filter/Junk Move of relevant account in Tb? (Q2) If Junk Filter is enabled, what is logged in Junk filter log? Did Junk Move happen on some mails when this bug occurred? (Q3) Do you enable quarantine option? (Tools/Options/Security, Anti-Virus) (mailnews.downloadToTempFile=true) (Q4) If yes, is something logged in log file of anti-virus software? Did quarantine happen on some mails when this bug occurred? FYI. Bug 750630 is for following case. Who does do the classification = full mail download by 'Click Here' of fetch-heasdr-only mail. "Click Here" downloads full mail to Inbox, and tries to move the full mail to Inbox to message folder where partial mail is held. Message filter rule of "Move to folder" : "Apply Filter when: Checking Mail" => "Move to folder of message filter" wins(executed first) => "attempt to move mail from Inbox by Click Here" fails, and bug 750630 occurs. "Apply Filter when: Checking Mail(after classification)" => "Move mail from Inbox by Click Here" wins(executed first), so bug 750630 is worked around. => "Move to folder of message filter" is not executed.
after classification work around doesn't quite work for me. 1. for one thing, the moved messages are no longer marked as unread so it's difficult to tell new messages without changing all my filters to mark as unread. 2. the filters intermittently don't filter with "after classification" and everything just stays in the Inbox unless I do a manual filter. filtering only works sometimes --- maybe some other bug is being encountered.
(In reply to mango2994-one from comment #24) > after classification work around doesn't quite work for me. > 1. for one thing, the moved messages are no longer marked as unread >(snip) As seen in bug 750630, "after classification" means that execution of the message filter action is done after someone checked headers/content of a mail. i.e. When "after classification", "Unread/Read status of newly-arrived/moved-by-message-filter mail" is all up to "someone" who accesses the mail before "Move to folder" of Tb's message filter. For example, if IMAP, and if the "someone" issues "uid xx fetch body[...]" instead of "uid xx fetch body.peek[...]"(Tb uses this), IMAP server automatically changes mail's status to Read(add \Seen flag) according to IMAP spec, even if the "someone" never executes "uid xx store +Flag \Seen". This case? If so, add explicit action of "mark as Unread", "mark as starred", "add tag" etc. to your message filter rule(s). > 2. the filters intermittently don't filter with "after lassification" > and everything just stays in the Inbox unless I do a manual filter. Major case of this bug is for following(perhaps). If not "after classification", "someone" deletes or moves mail or mail data just before Tb's message filter tries to write filter log for action=Move to folder. If "after classification", Tb applies filter rule to a mail after the "someone" deletes or moves mail or mail data, so the mail doesn't hit the filter rule, thus filter log of Epoc date, null subject, ... won't occur. Why can mail which is not moved by Tb's message filter be relevant to this bug? Is the mail actually "moved by Tb's message filter if not after classification" and actually "not moved by Tb's message filter only when after classification"? What is written in message filter log for the not-moved-by-Tb's-message-filter mail? Please note that followings are known but all is different problem from this bug. - If IMAP, Body filter works only when manual run on Offline-use=On folder, because message body is available in this case only. - Because Tb doesn't write filter log for "copy/move error", and because Tb silently fails when copy/move failure happens due to something wrong, following phenomenon may occur. - Log of "Move/Copy to folder" for a mail is written in message filter log, but the mail is not successfully moved to target folder.
All & Ole Junker, I withdraw my BINGO. Yes, the filter log shows a date that I expected. BUT... the messages do not show as "NEW" !and! the folder tree no longer shows RED for new additions; the folders stay black . I can live without the proper date in the filter log, BUT I CANNOT live with no notification of new messages in folders. And yes...In the filter I set "Mark as unread". Still no JOY. BTW All my messages come in via pop3, delete from server. Not IMAP. Anybody got a new plan???
(In reply to Dick Helwig from comment #26) > And yes...In the filter I set "Mark as unread". Still no JOY. Confusing but order in filter log is not always order of actions actually taken by Tb... When following rules are defined, with "who does do classification"="Click Here" of partial mail, rule-1 : before classification, if cond-A, add Tag-1 rule-2 : after classification, if cond-A, add Tag-2 rule-3 : after classification, if cond-A, move to FolderX, add Star filter log is written in following order. rule-1 : before classification, if cond-A, add Tag-1 <= Move to other folder by "Click Here" looks here(but not) rule-2 : after classification, if cond-A, add Tag-2 rule-3 : after classification, if cond-A, add Star <= Move to other folder by "Click Here" is actually executed here. rule-3 : after classification, if cond-A, move to FolderX However, Tag-1, Tag-2, and Star is added to mail which is downloaded by "Click Here" and moved to other folder(partial mail is held). And, even though log for "rule-3, move to FolderX" is written in filter log, mail is not moved to FolderX, because the mail is already moved to other folder by the "classification". "Mark as Unread" by your message filter rule is perhaps superceded by marking as Read done by "who does do classification" when "after classification" is requested. If your problem is phennomenon of funny filter log of "Epoc time, no sugject, ..." only, and if Read status by "who does do classification" is so critical for you, I don't think workaround of "after classification" is mandatory. If workaround of "after classification" is mandatory in your environment, consider utilizing Star("flag" in older Tb, \Flagged flag in IMAP) or Tb's Tag(user defined flag in IMAP=keyword in IMAP). If cause of funny filter log of "Epoc time, no sugject, ..." is virus-scan by anti-virus software + quarantine option=On of Tb, disable virus-scan by anti-virus software on Tb's profile directory(at least Tb's mail directory). Recent anti-virus software usually already has port scan type(or proxy type/SSL tunnel type if SSL) incoming/outgoing mail scanner.
(In reply to Dick Helwig from comment #26) > I withdraw my BINGO. Yes, the filter log shows a date that I expected. > BUT... the messages do not show as "NEW" !and! the folder tree > no longer shows RED for new additions; the folders stay black. If cause of this bug is mailnews.downloadToTempFile=true and qurantine by anti-virus software(delete of temp file, or erase of mail data in temp file) or something else which is similar to it, I think "unexpected Read status after filter move" can't occur simply by change to "after classification". And, even if the "someone does do classification just before filter move by message filter" is Junk Filter of Tb, AFAIK, Junk Filter of Tb doesn't change Unread status of new mail to Read. As seen in bug 750630, "Click Here" of fetch header mail can act as "someone who does do classification". Do you use addon relevant to message filter, Unread/Read status of mails etc.? Do you see "Read status with 'after classification'" with Tb's safe mode? (thunderbird.exe -safe-mode)
hello, The dates in the filter-log are correct in a new filter. In the old filter, before 2.17, stand uncorrect. sinserly Bertrand
(In reply to Dick Helwig from comment #26) > I withdraw my BINGO. Yes, the filter log shows a date that I expected. > BUT... the messages do not show as "NEW" !and! the folder tree > no longer shows RED for new additions; the folders stay black. Dick Helwig, stop enabling workround of "after classification", and continue problem analysis, please, because you look to need Unread status after filter move, and because you look torelant with useless filter log for "move to folder" :-) Following is copy of comment #9 by MediaDog. > (A) I am also seeing this problem with TB 13 and now 14.0. This makes the > filter log USELESS as almost all of my emails are sorted into folders, and > it is then impossible to identify messages in the log. > (B) A workaround is to set the junk score in the filter rule before the move; It sounds that all or almost all or many of "move to folder" logs has garbled data. And, it sounds Junk Move related phenomenon, because "Setting Junk Scrore in filter rule" is a workaround. "Setting junk status in message filter" is for; When Non-"after classification", disable Junk detection of mails after "move to a mail folder by message filter", and disable Junk move of the moved mails. (status of "Junk check is already done" can be notified to) (Junk filter by setting "Junk status = Not Junk". ) Dick Helwig, can you use Tb with following filter setting? - Non "after classification", as usual. - Add action of "Junk status = Not Junk" to filter rule which has action of "move to folder". By the way, Dick Helwig, do you use "action of Delete Message" or "Stop Execution" in your filter rule? Do you have action like "Set Junk Score..."(perhaps by addon) in message filter?
(In reply to MediaDog from comment #22) > The option to filter "after classification" is greyed out in > filters for all my accounts except for local folders. Global Inbox, with "deferred_to_account=Local Folders"? If so, it's by design. When Global Inbox is used, mail is temporarily downloaded to Inbox file for each hidden POP3 account with adding X-Account-Key:, and after filter application of message filter for each account, non-moved mail is moved to Inbox of Local Folders. So, "after classification" is not applicable. After move to Inbox of Local Folders, it's similar to download of ordinal POP3 account. MediaDog, is following also effective workaround in your case? "Junk status = Not Junk" in filter rule for "move to folder" in message filter for each hidden POP3 account. You say "set the junk score" is a work around. Do you use addon to set "Junk Score" instead of standard "Junk status = Junk/Not Junk"?
If problem is simply "mail is moved by Junk Move just before Tb's message filter writes filter log for move to folder", the mail shouldn't remain Inbor or in move target folder of "Move to folder", and Junk mark should be shown for each Junk-Move'ed mail. Problem like following? - Junk detection by somone is invoked just befoe Tb's message filter writes log for "Move to folder". - The unknown "Junk Detection" alters mail data and/or mail meta data such as data offset, data length, ..., while Tb's message filter is running. To bug opener and all problem reporters : Do you enable feature of PC side anti-virus software such as "add junk detection result in message header, Subject: etc."?
(In reply to bertranddepommery from comment #29) > hello, > The dates in the filter-log are correct in a new filter. In the old filter, > before 2.17, stand uncorrect. > sinserly > Bertrand Hello, that is not durable : that is good the 2013/06/11, and false then 2013/06/12... whith the same filter... (not the same message) What append ? Sincerly Bertrand
(In reply to WADA from comment #25) > (In reply to mango2994-one from comment #24) > > after classification work around doesn't quite work for me. > > 1. for one thing, the moved messages are no longer marked as unread > >(snip) > > As seen in bug 750630, "after classification" means that execution of the > message filter action is done after someone checked headers/content of a > mail. > i.e. When "after classification", "Unread/Read status of > newly-arrived/moved-by-message-filter mail" is all up to "someone" who > accesses the mail before "Move to folder" of Tb's message filter. > For example, if IMAP, and if the "someone" issues "uid xx fetch body[...]" > instead of "uid xx fetch body.peek[...]"(Tb uses this), IMAP server > automatically changes mail's status to Read(add \Seen flag) according to > IMAP spec, even if the "someone" never executes "uid xx store +Flag \Seen". > This case? > > If so, add explicit action of "mark as Unread", "mark as starred", "add tag" > etc. to your message filter rule(s). > > > 2. the filters intermittently don't filter with "after lassification" > > and everything just stays in the Inbox unless I do a manual filter. > > Major case of this bug is for following(perhaps). > If not "after classification", "someone" deletes or moves mail or mail data > just before Tb's message filter tries to write filter log for action=Move to > folder. > If "after classification", Tb applies filter rule to a mail after the > "someone" deletes or moves mail or mail data, so the mail doesn't hit the > filter rule, thus filter log of Epoc date, null subject, ... won't occur. > > Why can mail which is not moved by Tb's message filter be relevant to this > bug? Is the mail actually "moved by Tb's message filter if not after > classification" and actually "not moved by Tb's message filter only when > after classification"? What is written in message filter log for the > not-moved-by-Tb's-message-filter mail? > Please note that followings are known but all is different problem from this > bug. > - If IMAP, Body filter works only when manual run on Offline-use=On > folder, because message body is available in this case only. > - Because Tb doesn't write filter log for "copy/move error", and because > Tb silently fails when copy/move failure happens due to something > wrong, following phenomenon may occur. > - Log of "Move/Copy to folder" for a mail is written in message filter > log, but the mail is not successfully moved to target folder. note: using POP not IMAP. for all the messages not working using "after classification" ---- they all are filtered using "Sender" field, whereas all others that don't use the "Sender field consistently work fine. I must manually run the single filter for it to work properly. another issue is that if I click "run filters" from menu, I cannot tell that anything worked, and the filters w/ "Sender" still do not work until I go directly to the filter and run that specific filter manually. AGREED this is a different problem, and I don't know if I should be talking about it here, probably should make a new bug report.
(In reply to mango2994-one from comment #34) > note: using POP not IMAP. > for all the messages not working using "after classification" ---- > they all are filtered using "Sender" field, (snip) > AGREED this is a different problem, (snip) probably should make a new bug report. This bug is for problem of "Filter log records blank From, Subject, & Message ID, and default Date & Time", as clearly stated in bug summary since initial open of this bug. This bug is not for generic "message filter doesn't work as expected". "Sender" in filter was/is; (a) Initial: generic term for "mail sender. From:, Sender:, ... , is used (b) After term change from "Sender" to "From" : "From" is generic term for "mail sender". From:, Sender:, ... , is used (c) In any case, cutomized header of "from/From" or "sender/Sender" can be defined to check text string in From: header or Sender: header. Problem around uppercase/lowercase of (c) in msgFilterRules.dat, "sender" or "Sender" for (c) as string in msgFilterRules.dat, may be still remain, due to chaos by change from (a) to (b). For problem after workaround of this bug, problem after workaround of "after classification", problem in normal message filter execution after this bug was successfully bypassed, check filter definitions in msgFilterRules.dat, and read bug such as Bug 716365, Bug 460737 well if "Sender" relevant issue, and, after search bugzilla.mozilla.org well, open new bug if new problem, please.
Whiteboard: [known workaround : "after classification"]
I posted Bug 933352 which turns out to be a duplicate of this bug. However, you might want to look at this workaround: MOVE and DELETE do not capture timestamp and user info in the log (date is 31 Dec 1969). (DELETE is basically a MOVE to Trash.) But if you do a PUT-STAR prior to the MOVE or DELETE, then it not only captures time & info for the PUT-STAR but now also has it for the MOVE or DELETE. But strangely, although TAG will also capture time & info, its subsequent MOVE or DELETE does not. I also noticed that DELETE FROM POP3 also captures the time & info, although a corresponding DELETE does not.
Further to my Comment #37: After further testing, it seems that the PUT-STAR workaround allows info to be logged by MOVE and DELETE ON POP3, but it does *not* work for local DELETE. But at least the PUT-STAR itself identifies the message.
(In reply to Dan Pernokis from comment #37) > MOVE and DELETE do not capture timestamp and user info in the log (date is 31 Dec 1969). (DELETE is basically a MOVE to Trash.) Action=Delete and Action=Stop Filter Execution has severe problem(fixed in nightly/beta only). See bug 537501, bug 552936, bug 695671 etc. Please don't port problem due to Action=Delete in to this bug.
(Correction of my comment #31) > When Global Inbox is used, mail is temporarily downloaded to Inbox file for each hidden POP3 account with adding X-Account-Key:, > and after filter application of message filter for each account, non-moved mail is moved to Inbox of Local Folders. > So, "after classification" is not applicable. > After move to Inbox of Local Folders, it's similar to download of ordinal POP3 account. It seems wrong. Recent Tb looks to directly downloads POP3 mail into Inbox of Local Folders, instead of download to hidden Inbox for account of Global Inbox use. - No file writing is observed on hidden Inbox for account of Global Inbox use upon download. - After filter move for for account of Global Inbox use, "Truncate at Inbox of .Locaal Folders" is observed. This is perpaps done to avoid garbge in hidden Inbox. And, it may be a resaon why "contention among Global Inbox use accounts" started to occurr. - Download t each pop3 account is executed concurrently. - Before change : download is done to hidden Inbox for each POP3 account. Non-filter-moved mais are moved to Inbox of Local Folder at once. - After change : download is done to Inbox of Local Folder at same. If this is correct, as for this bug, there is no difference between non-Global Inbox and Global Inbox in POP3 case.
My guess about this bug. 1. Message filter of "Filter Before Junk Classification" uses "temporry messageKey upon mail download". (because messageKey=messageOffset currently when BerkleyStore, final messageKey is perhaps set after completion of download/filter move.) (if mail is moved by filter, temporary msgDBHdr is removed, and "Truncate at file size just before download of this mail" is executed.) 2. If Junk Filter is invoked for Junk Filtering while message filtering is being executed, messageKey is changed to final one. 3. Because messageKey is changed, "Logger of filter move" fails to fing message header data. 4. "Filter move action" is executed based on Offset of currently processed mail(==file size of Inbox just before download of this mail), "move to taret folder" itself is executed normally. And, "truncate at file size just before download of this mail" is executed, .so garbage data won't occur in file named Inbox. Even if msgDBHdr for this "filter moved mail" is not deleted, same "messageKey==messageOffset==current file side of Inbox" is used bt next mail. So, no garbage remains in msgDBHdr too. If my guess is not so wong, if messageKey=messageOffset will be stopped in BerkleyStore and if messageKey is changed to "starts from 1, increment by 1", problem lke this bug will be resolved. See bug 854798 for messageKey in Compact Folder of BerkleyStore,
Note: If multiple pop3 mails are moved to a "filter move target folder(local mail folder)" by message filter of "Filter Before Junk Classification" within a "pop3 mail download", following is observed in the "filter move target folder". Currently, messageKey=messageOffset in many place, but message filter(Filter Before Junk Classification") uses new rule of "increment by 1" on messageKey. So, at Order Received column(messageKey value is shown), following data is shown. Order Received filter moved mail #1 : NN = file size before append this mail, or file size before append this mail + 1 filter moved mail #2 : NN + 1 filter moved mail #3 : NN + 2 filter moved mail #m : NN + (m-1) If Compact is executed by current Tb, this is changed to messageKey==messageOffset, so value is drastically changed. If Compact is executed by Tb on which bug 854798 is landed, Order Received column value is unchanged by Compact. I think similar "increment by 1" is used for "temporary messageKey upon pop3 download + filter move".
FYI. Change like comment #42(messageKey is incremented by 1 if filter move of pop3 mails to local BerkleyStore mail folder) is phenomenon from Tb 12 by which "Plugguable msgStore" was introduced. (messageKey and messageOffset was clearly seprated by this change) And, this bug was reported for Tb 12.
Oh, problem is already fixed by bug 935934. Why patch was not proposed in this bug? Anyway, closing as dup of bug 935934.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
No longer blocks: 935934
You need to log in before you can comment on or make changes to this bug.