Open Bug 1746798 Opened 4 years ago Updated 8 months ago

Attachments sometimes don't save properly when messages not synchronized to local disk

Categories

(Thunderbird :: Message Reader UI, defect)

Thunderbird 96
defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: 52qtuqm9, Unassigned)

References

Details

Just observed this in 96.0b2 on Linux.

  1. 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)
  2. Repair the folder to ensure that messages are not stored locally
  3. Right click on an attachment and save it somewhere
  4. 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.

TCW do you see and bug 1547428 on Windows?

Flags: needinfo?(thee.chicago.wolf)

(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.

Flags: needinfo?(thee.chicago.wolf)

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?

Flags: needinfo?(jik)

Still seeing this in 96.0b4.

Flags: needinfo?(jik)

Also reproducible for me in 96.0b4 on macOS.

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)?
Flags: needinfo?(jik)

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.

Flags: needinfo?(jik)

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
See Also: → 1747987, 1727951

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

Is this still seen with a current version, now at 140?

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.

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