Summary: | Sometimes the message body is missing | ||||||
---|---|---|---|---|---|---|---|
Product: | Claws Mail (GTK 2) | Reporter: | nfxjfg | ||||
Component: | Folders/IMAP | Assignee: | users | ||||
Status: | NEW --- | ||||||
Severity: | normal | CC: | emblemparade, schwarzb | ||||
Priority: | P3 | ||||||
Version: | 3.10.1 | ||||||
Hardware: | Other | ||||||
OS: | All | ||||||
Attachments: |
|
Description
nfxjfg
2014-09-05 20:32:47 UTC
Further observation: the mail without body has the sender (and other metadata) of the previous mail (at least in this case: the mail in the mailing list thread that was replied to). It would appear that the body did not get cached. Start Claws in debug mode, `claws-mail --debug`, and attach the relevant output. I've also seen this (starting with claws 3.10 (IIRC), now using 3.11.1). It happens here with an IMAP account at an xchange-server. However the missing bodies can be fetched completely after the incomplete, cached imap mail file (located in claws' imap-chace directory) has been deleted manually. The problem seems to be the server sometimes reporting zero body length when the message is cached the first time. A possible workaround would be to let claws re-fetch cached messages when their body length is 0. For further analysis, see the attached commented_claws-mail_debug-output.txt. It contains apparently relevant parts of the (huge) full debug log generated with claws-mail --debug. There a message (ID 75684) has been fetched/cached initially resulting in an incomplete body (see line 65). Every log line where this ID is present has been left in the log file with some context. Later the cached message was deleted (rm) and then re-fetched, now with the complete body. Interestingly the first fetch is initiated by UID FETCH 75684 BODY.PEEK[HEADER] but later claws "thinks" the cached mail was already complete. Created attachment 1466 [details]
commented_claws-mail_debug-output
(In reply to comment #3) > The problem seems to be the server sometimes reporting zero body length > when the message is cached the first time. now i think im'm wrong here, see further text of comment #3 |