saving many attachments from a mail by drag'n'drop -> some files are saving with zero length



13 years ago
6 years ago


(Reporter: abc, Unassigned)


Windows XP

Firefox Tracking Flags

(Not tracked)


User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; cs; rv: Gecko/20070309 Firefox/
Build Identifier: verzion 2 beta 2 (20070116)

when saving attachments (fles) (drag and drop metod) from mail (if mail has many (e.g. 10 and more attachemnts) some files are saved with zero lenght. (both in mail window and in preview pane too). This file(s) (really) have not zero lenght. The number of files saved with zero lenght is random. When is used function "save as" (right click on file) the file is saved correctly. (with no zero size). I found this problem with Attachment extractor extension, but  when i saved files manualy problem repeat. The problem occurence is random. Sometime problem is, sometime no, but recur.

Reproducible: Sometimes

Steps to Reproduce: mail window (mail has many attachments) files to any folder with drag and drop metod.  (one behind the other)
3.some files have zero lenght/size. 

the same process in preview pane

save files with Attachment Extractor extension
Actual Results:  
some files have zero lenght

Expected Results:  
all files should be their own correct size

i have winxp pro, sp2. cz
If you can reproduce, any additional info would be nice. Also if you can figure out why it only happens sometimes.
Summary: when mail has many (eg 10 and more) atachemnts - some files are saving with zero lenght → saving many attachments from a mail by drag'n'drop -> some files are saving with zero length
Version: unspecified → 2.0
Reporter, does the issue still occur in the latest supported 2.0.0.x / Shredder trunk nightlies?

(1.5.0.x is now end-of-life and the latest supported 2.0.0.x is now
Whiteboard: closeme 2008-08-21
RESO INCO per lack of response to previous comment. If you feel this change was made in error, please respond to the bug with your reasons why.
Closed: 11 years ago
Resolution: --- → INCOMPLETE
I'd like to re-open this bug.

I'm using tb 3.0b2 and drag-and-drop attachments to my desktop fails every single time: I get a zero-byte file. I had been running the nightly builds and figured it was just something that was temporarily broken, so I downgraded to 3.0b2 and it's still exhibiting this behavior.

I'm happy to instrument tb to find out what's going on, but I don't really know what I'm doing. I'm a software dev so I'm willing to try; I just need some pointers for how to actually set that up.
nb: This happens to me for /every/ file, including individual files. I haven't even tried multiple files at once.

Right-clicking and choosing "Save As..." works correctly.
I would say that this is a dupe of, and is being tackled in, bug 227305 - Support drag-drop messages to desktop / file-system window (e.g. Explorer).
Duplicate of bug: 227305
I'm not convinced this is a dup - that bug is about messages, not attachments. Re-opening
Resolution: DUPLICATE → ---
Ever confirmed: true
Thanks for your attention.

Right, this is about dragging and dropping attachments out of tb. If I drag a single attachment and drop it onto the desktop or anywhere else in explorer, I get a correctly-named file of zero bytes. If I select multiple files and drag-and-drop them, it appears that only the exact file I used to initiate the drag-and-drop operation is considered, and I get the single-file behavior (single zero byte file).

I'm using Microsoft Windows Vista sp1, and this is the build string for my tb instance: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2

Please let me know if there's anything I can do.
(In reply to comment #7)
> I'm not convinced this is a dup - that bug is about messages, not attachments.
> Re-opening

Oh yes, sorry, my bad.

WinXP only?
If reopening a closeme, please clear the closeme from the status whiteboard.
Whiteboard: closeme 2008-08-21
Christopher: if you're willing to code, you can get started from the code around  onDragStart at

To get a build set up, see and
Assignee: mscott → nobody
Okay, I must admit I'm quite out of my league here: I can read and write Javascript but my lack of knowledge of the Mozilla APIs makes this a difficult task.

Honestly, I'm not sure how I would even patch my own installation if I were to update msgHdrViewOverlay.js with some additional code.

I'm willing to try, but I suspect I won't get very far without some hand-holding.
I posted an update to bug #437388 comment #2. I'll repeat it here:

I recently upgraded to 3.0b3 (Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US;
rv: Gecko/20090715 Thunderbird/3.0b3) on Vista and drag-and-drop
appears to work on attachments for both encrypted (enigmail 0.96a, GnuPG
1.4.9/MingW32) /and/ non-encrypted messages.

- multiple-attachment drag and drop doesn't work as expected (only the file you
were pointing to when initiating the multi-file-drag is saved)
- dragging-and-dropping a file that will replace one that already exists
results in Windows Explorer (on Vista) to report that the new file's size is 0
bytes (for both encrypted and non-encrypted attachments)
Er, sorry: to be clear: explorer says that the file size /will be/ 0 bytes if you replace the existing file. Choosing "Copy and Replace" does give you a correctly-sized file.
(In reply to comment #1)
> If you can reproduce, any additional info would be nice. Also if you can figure
> out why it only happens sometimes.

This bug also exists without using drag 'n drop. If you right-click on an empty spot in the right of the file attachment display area, a menu pops up, one of the options being "Save All ...". Selecting that option when you have a large (>10) number of attachments sometimes saves zero-byte files. The problem worsens (occurs more frequently) when the account with the email is an IMAP account and the server is remote. I can reliably reproduce the problem with 30 or so attachments on a remote IMAP server.

If you repeat the procedure, overwriting the files, the files are usually saved with the correct size - but you have to respond to each "overwrite this file?" message individually. While I know nothing about the internals of Thunderbird, it seems to be some kind of timing issue when you have a large number of attachments, in that a main thread assumes that individual file writing threads are complete when they are not. Forcing Thunderbird to write only one file at a time (by repeating the save procedure and answering the overwrite prompt) seems to avoid the problem.
You need to log in before you can comment on or make changes to this bug.