Closed Bug 471304 Opened 16 years ago Closed 13 years ago

Dragging large attachment from Thunderbird window to explorer results in corrupt file

Categories

(Thunderbird :: General, defect)

x86_64
Windows Vista
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: msamek, Unassigned)

References

Details

(Whiteboard: [closeme 2011-10-11])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 (.NET CLR 3.5.30729)
Build Identifier: 2.0.0.18 (20081105)

I am using an IMAP gmail account. I have an email with a large attachment(6 meg). The attachment is a PDF file. When I drag and drop it into an explorer window, and then try opening it, the PDF is corrupt. If I open it by double clicking in the thunderbird window, the PDF opens OK. If I save as into a windows folder, the PDF opens OK.

I have tried it repeatedly and so am sure that the attachment is fully downloaded. Every time I drag and drop, the result is corrupt. When I open the attachment using some other means it works.

This is 100% reproducible with this attachment. I have another email with an attachment the same size and it works OK, even with drag and drop.

The corrupted file appears to be truncated to 4.87 megabytes, instead of the origina 6.




Reproducible: Always

Steps to Reproduce:
1.Drag large PDF from thunderbird to windows explorer window
2.Open the result by checking size or trying to open it in acrobat
3.
Version: unspecified → 2.0
similar to bug 404946 (Dragging attachments into Windows Explorer doesn't work if attachment not entirely downloaded), perhaps dupe?
Whiteboard: dupme
(In reply to comment #1)
> similar to bug 404946 (Dragging attachments into Windows Explorer doesn't work
> if attachment not entirely downloaded), perhaps dupe?

I don't think because Marcel wrote:
>I have tried it repeatedly and so am sure that the attachment is fully >downloaded.
This bug is still present in TB3 and it is also not windows specific as I'm seeing this on a Mac.
This bug has been around for a long time and is really annoying.
WFM
gmail drag and drop 10 meg file produced byte identical file.

problems:
1. our b/e and windows shell don't play well together and the file is downloaded twice, I believe it is once for stream type and once for the CF_HDROP type but not sure.
2. it really should be sent to the download folder so progress can be observed plus other benefits of download folder. Bug 501054

disclaimers:
I have patches for bugs installed that may or not make a difference but I wouldn't think so. bug 462172, bug 494989, bug 484667, bug 497797, bug 491239, bug 356808, bug 524852, bug 244741, bug 246415

maybe a imap log would help from someone with problem.
This bug doesn't always occur. I think the original reporter meant that it always happens for one particular e-mail, but not for all e-mails. How do you access the IMAP log?
(In reply to comment #5)
> This bug doesn't always occur. I think the original reporter meant that it
> always happens for one particular e-mail, but not for all e-mails. How do you
> access the IMAP log?

https://wiki.mozilla.org/MailNews:Logging
I think it will be a huge log with the large attachment being downloaded. Most of it can be deleted where it goes on and on downloading the attachment. If the deletable lines aren't obvious in the log file then maybe zipping it before uploading will help.
this behavior is due to You drop file very quickly. it have to wait a few seconds before drop file into file manager.
Do you see this in version 6 or newer?

if you no longer see problem on newer release, please change resolution to WORKSFORME.
if you do see the problem on newer release, please update the bug with details.
Whiteboard: dupme → [closeme 2011-10-11]
RESOLVED INCOMPLETE due to lack of response to previous question. If you feel this change was made in error, please respond to this bug with your reasons why.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.