Re: [Tracker] Initial email indexing support

[Laurent Aguerreche <laurent aguerreche free fr>]

Le dimanche 24 septembre 2006 Ã 22:42 +0200, Laurent Aguerreche a
Ãcrit :
> Le dimanche 24 septembre 2006 Ã 16:33 -0400, Samuel Cormier-Iijima a
> Ãcrit :
> > On 9/24/06, Laurent Aguerreche <laurent aguerreche free fr> wrote:
> > > Le jeudi 21 septembre 2006 Ã 16:47 +0100, Jamie McCracken a Ãcrit :
> > > > Laurent Aguerreche wrote:
> > > > > Le jeudi 21 septembre 2006 Ã 00:50 +0100, Jamie McCracken a Ãcrit :
> > > > > > Laurent Aguerreche wrote:
> > > > > > > Le mercredi 20 septembre 2006 Ã 14:11 +0100, Jamie McCracken a Ãcrit :
> > > > > > > > Laurent Aguerreche wrote:
> > > > > > > > > Hello,
> > > > > > > > >
> > > > > > > > > this is a patch for an initial email indexing support with Evolution. It
> > > > > > > > > extracts content of sent and received emails: text + attachments.
> > > > > > have now applied to cvs with a few changes:
> > > > > >
> > > > > > 1) added tracker_notify_file_data_available () after pushing data onto queue
> > > > > >
> > > > > > 2) mbox files should not get to extract_metadata thread so have changed
> > > > > > them in index_files. Only attachements can get on this thread.
> > > > > >
> > > > > > 3) set the default email config options to false as its not yet complete.
> > > > > >
> > > > > > Otherwise really good work :)
> > > > >
> > > > > Ok.
> > > > >
> > > > >
> > > > > I send a patch to extract info from evolution mails to know whether they
> > > > > are deleted or junk. As I said before, Evolution is completely buggy...
> > > > > On my mbox almost all my mails are seen as deleted! I report a trivial
> > > > > bug that I found in code source but I don't know if it is the (or a?)
> > > > > culprit.
> > > >
> > > > Is there a difference in the flags when you explicitly delete a mail as
> > > > opposed to a new mail?
> > >
> > > Yes. X-Evolution field in email's headers is modified. For instance:
> > >   X-Evolution: 00002019-0092
> > > where only "0092" is interesting for use.
> > >
> > > Suppose you receive an email that only contains text (no attachments, no
> > > pgp signature, etc.):
> > > - new (unseen): 0000,
> > > - seen: 0010,
> > > - deleted: 0012,
> > > - junk: 0090,
> > > - deleted and junk: 0092.
> > >
> > >
> > > Now, let see how flags are declared:
> > >
> > >  EVOLUTION_MESSAGE_ANSWERED     = 1 << 0,
> > >  EVOLUTION_MESSAGE_DELETED      = 1 << 1,
> > >  EVOLUTION_MESSAGE_DRAFT        = 1 << 2,
> > >  EVOLUTION_MESSAGE_FLAGGED      = 1 << 3,
> > >  EVOLUTION_MESSAGE_SEEN         = 1 << 4,
> > >  EVOLUTION_MESSAGE_ATTACHMENTS  = 1 << 5,
> > >  EVOLUTION_MESSAGE_ANSWERED_ALL = 1 << 6,
> > >  EVOLUTION_MESSAGE_JUNK         = 1 << 7,
> > >  EVOLUTION_MESSAGE_SECURE       = 1 << 8
> > >
> > > So (0090) = (1011010)b and it means:
> > > - deleted,
> > > - flagged,
> > > - seen,
> > > - answered all.
> > >
> > > It is completely different from what I described!
> >
> > These are supposed to be hex, i.e. 0090 = 10010000b, so it's junk and
> > it's been seen. Similarly, 0010 = 00010000b, so that means it's just
> > been seen.
>
> Mmmmmmmmm... Ok.
>
> Thank you.

So this is an amended patch to correctly read evolution flags.  :-)
It is a cumulative patch: my work on thunderbird + fix for evolution
flags.


Laurent.

Attachment: thunderbird-support.diff.gz
Description: GNU Zip compressed data