1168620 - Incomplete filter log fails to record From:, Subject:, and recorded Date: time stamp is Unix epoch? (Maybe a problem in non-US-ASCII locate?)

Status: RESOLVED DUPLICATE of bug 935934

(Thunderbird :: Filters, defect)

Description

[ISHIKAWA, Chiaki]

Attachment: Incomplete log of successful filter action: From:., subject: missing, and date is that of Unix epoch. incomplete-japanese-log.png

Hi, I have noticed that the CURRENT release version of thunderbird seems to fail to record the 
From:, Subject: information for successful filter action.
Also, the date information recorded there seems to be that of Unix epoch or something.

I noticed this both under linux and Windows7.

But I am using Japanese locale and I wonder if that could be the cause of the issue. It is possible that the StringBundle for Japanese may not have the proper substitution character "%S" or "%s". 

FYI, I am uploading an INCOMPLETE message log that is recorded 
using Windows version of the CURRENTLY RELEASED thunderbird 31.7.0
in Japanese locale.

Comment 1

[ISHIKAWA, Chiaki]

Attachment: A cmplete log message that is recorded by C-C TB using C localte. : successful-english-log.png

For comparison purposes, I am uploading a complete log of successful filter action recorded by a locally built full debug version of COMM-CENTRAL TB.
This is in C locale, I think.
You can see that this log shows the From:, Subject: properly and Date: seems also good.

I will investigate if the stringbundle for the Japanese locale is not good, or if there is a problem in the released code.

I hope the filter logging would be good enough in the current release, but
I am afraid it may be broken still :-(

TIA

Comment 2

[ISHIKAWA, Chiaki]

Additional problem.

I just realized that message ID info is not shown in the Japanese log message in 
https://bugzilla.mozilla.org/attachment.cgi?id=8610855

Message ID is shown in https://bugzilla.mozilla.org/attachment.cgi?id=8610858

The code looks innocent, and so I wonder where to look.

First, I have to ask where the filter.properties (and its I18N counterpart) are stored
in local installation (as opposed to developer's source tree.)
I suspect they are bundled with other properties files and possibly compressed and stored in one's profile? (But under what name?)

TIA

Comment 3

[:aceman]

What is the filter action done on the message that produced the bad log message? Is it MOVE TO folder?

What is the TB version that produced this? You say it is CURRENT version but then later on say 31.7.

Comment 4

[ISHIKAWA, Chiaki]

(In reply to :aceman from comment #3)
> What is the filter action done on the message that produced the bad log
> message? Is it MOVE TO folder?
> 
This is MOVE to filter.
(That is the only action I use for many filters.)

> What is the TB version that produced this? You say it is CURRENT version but
> then later on say 31.7.

Sorry, I meant to say "currently released to the public" version. (not comm-central)
And the current released version on my Windows 7 is 31.7.0

Comment 5

[:aceman]

Can you check if this is the same as bug 935934, which got fixed in TB36 ?

Comment 6

[ISHIKAWA, Chiaki]

(In reply to :aceman from comment #5)
> Can you check if this is the same as bug 935934, which got fixed in TB36 ?

Ouch, it looks like this is the same bug from my cursory reading.
But I didn't realize that there are so many subtle issues regarding the filter actions (and error logging).
I will study the mentioned bug 935934 again, and if I am convinced, I will
change this to the duplicate of the bug.

TIA

Comment 8

[Dan Pernokis]

Hey Aceman...  re: Comment 5
This comes as a reminder that the problem aka Bug 935934 was supposed to be fixed -- but you say in TB 36?  When will that version be officially released?  (I'm still seeing it fail in TB 31.7.0 also, and it's the US/Canada ASCII version with no unusual, special, or foreign settings.)

Comment 9

[:aceman]

The TB31.x line is not getting the fix. But it will be released in TB38 in a matter of days now.