Attachments sometimes don't save properly when messages not synchronized to local disk
Categories
(Thunderbird :: Message Reader UI, defect)
Tracking
(Not tracked)
People
(Reporter: 52qtuqm9, Unassigned)
References
Details
Just observed this in 96.0b2 on Linux.
- Disable message synchronization on a folder containing a message with a couple very large attachments (in my case, the total size of the message was around 25MB)
- Repair the folder to ensure that messages are not stored locally
- Right click on an attachment and save it somewhere
- Instead of the whole contents in the saved attachment file, you get just 27 bytes, though you don't get any error indicating that it failed to download or save
I don't think this happens on every message, but it happened for me reproducibly on a specific message.
If you enable synchronization and click the Download Now button on the folder and then save the attachments, they save fine.
Could be related to bug 1547428.
Comment 1•4 years ago
|
||
TCW do you see and bug 1547428 on Windows?
Comment 2•4 years ago
|
||
(In reply to Wayne Mery (:wsmwk) from comment #1)
TCW do you see and bug 1547428 on Windows?
I can't help here presently as my TB is unusable due to the repair folder issue in bug 1740486 and related issues.
Comment 3•4 years ago
•
|
||
Wait, I remember seeing something like this now that I think of it. It happened once, maybe twice with saving a PDF. The behavior was also akin to it not fully saving the attachment locally. I'd click Save As, save to Desktop and it would save a file of only a few bytes. I just bumped myself to the 96.0b4 test build and haven't been able repro my issue. Not exactly the STR but it used to not fully save the file. Again, I haven't been using my TB since at least early December since it's currently in a borked state.
Jonathan,
Are you able to bump up to 96.0b3 (or maybe the 96.0 b4 test build if you're feeling brave) and re-test?
Updated•4 years ago
|
| Reporter | ||
Comment 5•4 years ago
|
||
Also reproducible for me in 96.0b4 on macOS.
Comment 6•4 years ago
|
||
I've tried very hard and followed the excellent STR of comment 0 religiously, but I'm failing to reproduce this on
102.0.2 (64-bit), Win10.
On IMAP folder > Properties > Synchronization, I unchecked Select this folder for offline use, followed by Repair folder. Message went away and attachments were re-downloaded as the message was currently selected and displayed (for the inline preview I guess - oh, maybe you had that off?). Checking on file system, the folder size never went down, still at 25 MB which was the size of the single message contained. Saving attachment from message in allegedly non-synced folder then went right, image completely saved.
Jonathan, can you
- retest with 102.0.2?
- provide a test message (remove private data and no private attachments pls)?
| Reporter | ||
Comment 7•4 years ago
|
||
Still reproducible for me in 102.0.2 on macOS with the following message uploaded into my IMAP inbox: https://drive.google.com/file/d/1MdIMaWQqVpT6U5bK0b1LwtO5LZPimiRR/view?usp=sharing (it's too big to attach so I uploaded it to Google Drive).
One possible difference: I turned off synchronization for the entire account, not just for one folder. Don't know if that makes a difference.
Comment 8•3 years ago
|
||
Courtesy of QA:
- This looks very similar to:
Bug 1747987 - Corrupted opened/saved attachments from messages larger than 24.4MB on IMAP account with synchronization disabled - ...which in turn points to:
Bug 1727951 - IMAP Attachment Download Failing if attachment > 20MB
We're still seeing this problem sometimes on 102.10.0 (Win10 x64) for PDF attachments of any size. The ones today were 2MB and 5MB but the end result is still a file of 1kb on the disk. The forward and open them from there workaround works but isn't very nice. This is an IMAP inbox which isn't sync'ed locally. The memory cache settings referred to previously are as recommended.
Thanks.
Martin
Comment 10•1 year ago
|
||
Is this still seen with a current version, now at 140?
| Reporter | ||
Comment 11•1 year ago
|
||
I can no longer reproduce but we also never figured out exactly what triggered this and I no longer have the message that I linked to above to test with that exact message, so I can't say for certain that it's fixed.
Description
•