Closed Bug 1654995 Opened 4 years ago Closed 4 years ago

Thunderbird 79.0b2 corrupting large attachments because of chunking

Categories

(MailNews Core :: Networking: IMAP, defect)

defect

Tracking

(thunderbird_esr78+ fixed, thunderbird79 fixed)

RESOLVED FIXED
Thunderbird 80.0
Tracking Status
thunderbird_esr78 + fixed
thunderbird79 --- fixed

People

(Reporter: peterr, Assigned: gds)

References

(Regression)

Details

(Keywords: dataloss, regression, Whiteboard: [TM:78.2.0][ref bug 1580480])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36

Steps to reproduce:

I have checked e-mails with large > 2Mb and small < 100kb attachments, large

Actual results:

Large attachments are corrupted dwg files unreadable, pdf files partial or unreadable, jpg files display part of image. Same files downloaded direct from Yahoo are unaffected. Small files seem to be OK, don't have time or inclination to try multiples of various size files to ascertain problem cut off, but definately only happened since update on 16th July 2020

Expected results:

I would have hoped that all files would be received un-corrupted

Blocks: tb78found

but definately only happened since update on 16th July 2020

Related to bug 1580480?

Flags: needinfo?(vseerror)
Flags: needinfo?(gds)

Peter, so this is on beta? Do you see it with 78.0?

No longer blocks: tb78found
Keywords: regression
Component: Untriaged → Networking: IMAP
Product: Thunderbird → MailNews Core

Well, Peter filed it for 79.0b2.

Reporter Peter, I assume this is an imap account? If so, are you letting tb store your emails locally (the default) or keeping message bodies only on the server?
If stored locally, are the problem emails just now received or are they messages that have been present on the system and possibly opened OK before?
Would you characterize your network connection to your imap server as generally "fast" or "slow"?
Please look in the config editor and tell me the values you see for:
mail.imap.chunk_size = ?
and
mail.imap.min_chunk_size_threshold = ?
If they are bold font, try resetting them back to default and restart tb and see if that helps.
If that doesn't help, set mail.server.default.fetch_by_chunks to false and restart tb. Does that help?

Flags: needinfo?(gds)

Problem occurs on download, not with locally stored e-mails, fast connection 100Mbs, sadly new to all this so not sure how to get values you ask, but never had this problem until upgrade to 79.0b2 on the 16th so clearly associated with upgrade or it's interaction with other programs (security is Microsoft 10 own virus protection.

Actually I've been seeing the same problem and thought it was caused by something else I was working on. When the chunk size is changing (an old feature that was accidentally disabled years ago and recently revived, see Bug 1580480), the wrong offset into the message is sometimes calculated for the next chunk. It uses the new chunk size as the offset instead of the previous chunk size. This causes pieces of the message to be left out when chunk size increases, or causes pieces to be fetched again when chunk size goes down. Once the chunk size stabilizes to a constant value the problem goes away.
You can work around this by disabling chunking in the config editor. It's under advanced preferences or options: mail.server.default.fetch_by_chunks to false and restart tb.
This will fix any new messages but you may have to repair your folder to fix existing messages. Another way, instead of right-click/properties/repair folder is to copy the bad messages to another folder and then back to the original folder; do these fixes with chunking disabled.
A patch to fix this shouldn't be too hard. (Famous last words :).)
Thanks for reporting this!

This fixes the problem.

Assignee: nobody → gds
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #9166104 - Flags: review?(mkmelin+mozilla)

Problem fixed with Gene Smith's cure, thanks.

Comment on attachment 9166104 [details] [diff] [review] Bug1654995_fix-for-chunk-offset-on-size-variance-v1.patch Review of attachment 9166104 [details] [diff] [review]: ----------------------------------------------------------------- Thanks Gene! r=mkmelin
Attachment #9166104 - Flags: review?(mkmelin+mozilla) → review+
Target Milestone: --- → Thunderbird 80.0

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/1da0226308d3
Chunk starting offset wrong after m_chunkSize changes. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED

I assume bug 1580480 caused this?

Regressed by: 1580480

(In reply to Jorg K (CEST = GMT+2) from comment #11)

I assume bug 1580480 caused this?

Yes. We are going to back that out of the esr and not ship it until these both go through another round of beta.

Severity: -- → S2
Flags: needinfo?(vseerror)
Keywords: dataloss
Comment on attachment 9166104 [details] [diff] [review] Bug1654995_fix-for-chunk-offset-on-size-variance-v1.patch Approved for beta - 79.0b3
Attachment #9166104 - Flags: approval-comm-beta+

Rob, this will also need a release note

Flags: needinfo?(rob)
Summary: Thunderbird 79.0b2 (32 bit) corrupting large attachments → Thunderbird 79.0b2 corrupting large attachments because of chunking
Flags: needinfo?(rob)

Comment on attachment 9166104 [details] [diff] [review]
Bug1654995_fix-for-chunk-offset-on-size-variance-v1.patch

Can we get this on the way to ESR at some stage together with bug 1580480?

Attachment #9166104 - Flags: approval-comm-esr78?
Whiteboard: [TM:78.2.0]
Whiteboard: [TM:78.2.0] → [TM:78.2.0][ref bug 1580480]

Comment on attachment 9166104 [details] [diff] [review]
Bug1654995_fix-for-chunk-offset-on-size-variance-v1.patch

[Triage Comment]
Approved for esr78

Needs bug 1580480

Attachment #9166104 - Flags: approval-comm-esr78? → approval-comm-esr78+
See Also: → 1770811
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: