Last Comment Bug 802542 - Message size for IMAP folders incorrectly reported/updated in Tb 16
: Message size for IMAP folders incorrectly reported/updated in Tb 16
: regression
Product: MailNews Core
Classification: Components
Component: Networking: IMAP (show other bugs)
: 16
: All All
-- major (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
Depends on:
  Show dependency treegraph
Reported: 2012-10-17 03:19 PDT by Kaspar Brand
Modified: 2012-10-28 06:30 PDT (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---


Description User image Kaspar Brand 2012-10-17 03:19:00 PDT
The changes to nsImapMailFolder in bug 740453 (attachment 634391 [details] [diff] [review]) broke proper representation of the message size in the "Size" column for an IMAP folder.

When a message with an attachment is received, the following happens:

1) on the first retrieval of the message, all looks fine (and the size [in this case 46817 bytes] is accurately reported in the folder view):

2012-10-17 09:33:18.997000 UTC - 1832[ba65680]: * 16 FETCH (FLAGS (\Recent) UID 524 RFC822.SIZE 46817 BODY[HEADER.FIELDS (From To Cc Bcc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type)] {240}

2012-10-17 09:33:18.997000 UTC - 1832[ba65680]: Size: 46817: Begin Message Download Stream

2012-10-17 09:33:18.997000 UTC - 1832[ba65680]: Normal Message End Download Stream

2) Selecting the message retrieves the body structure, the headers and part of the body, and afterwards the size shrinks (to 1949 bytes in this case):

2012-10-17 09:33:49.994000 UTC - 1832[ba65680]: Size: 1939: Begin Message Download Stream

2012-10-17 09:33:50.025000 UTC - 1832[ba65680]: Normal Message End Download Stream

2012-10-17 09:33:50.056000 UTC - 0[100f140]: Updating stored message size from 46817, new size 1949

Moving the message to another folder shows the same effect: when it appears in the message list for the first time, the size is accurately reported, but as soon as it is selected/viewed, the size becomes corrupt.
Comment 1 User image Kaspar Brand 2012-10-28 06:30:35 PDT
Ok, so the second half of the patch in bug 803843 comment 28 (attachment 675468 [details] [diff] [review]) fixes this issue, too... would have been nice if I didn't have to figure this out myself (this bug predates bug 803843, after all). And yes, "for users with an existing wrong size in their message DB, they may need to manually rebuild the folder". Sigh.

Note You need to log in before you can comment on or make changes to this bug.