Re: [Evolution-hackers] Evo 2.0.3 not showing certain messages' content




> 
> > It looks like revision 1.337.6.1 of camel-imap-folder.c is causing this.
> > Specifically, the check at line 2005:
> > 
> > if (store->server_level < IMAP_LEVEL_IMAP4REV1
> >    || store->braindamaged
> >    || mi->size < IMAP_SMALL_BODY_SIZE
> >    || (!content_info_incomplete(mi->content) && !mi->content->childs)) {
> > 
> > Since there is no Content-type header, I think content_info_incomplete()
> > is returning TRUE, and thus my message is fetched in chunks.  Sure
> > enough, setting CAMEL_IMAP_BRAINDAMAGED=1 corrects this problem, but I
> > don't think imap-uw is truly brain damaged.  I'm wondering if
> > content_info_incomplete() can be fixed to accept such headerless
> > messages as text/plain instead of simply returning TRUE.  It seems like
> > that was the intention of camel_content_type_is() (i.e. we can pass a
> > NULL CamelContentType, and camel_content_type_is() will do the right
> > thing).  Thanks for any insight you can give.
> 
> I dont think there's a problem in that code as such, its probably the
> code which does the downloading of parts not working properly.

I took some sniffer traces, and I'm not so sure it's a problem with
downloading.  Evo downloads the size and headers as soon as it sees new
messages.  Then, it uses that information to determine how it should
download the rest of the body.  For these auto-generated messages
without a Content-type (usually CVS commit and bug reports), I see this
problem.
Yes, thats what i meant. If you're not seeing it right, then its not downloading it right.  Its not makign the right decsion about what to download based on its earlier queries.  It should get the header then later get the body for 'large' messages.

I guess a null came-content-type could match "text/plain" or "*/*" in camel_content_type_is.  On the other hand, perhaps the code which builds the content-info record for imap should create an empty (not null) content-type itself instead.
> 
> But that might be the easist workaround, default simple messages to
> download the whole rather than in header then content.

Shall I create a patch, and forward it to evolution-patches?
I guess, you can safely use 'braindamaged' if you want, it only means we only ever get full message fetches rather than try to get individual parts - depending on your mail load, it can be faster anyway.

--
Michael Zucchi <notzed ximian com>
"Ride, Work, Sleep. Beer."
Novell's Evolution and Free Software Developer


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]