Closed Bug 1640642 Opened 6 years ago Closed 6 years ago

large file is attached and linked to wetransfer - nevertheless the file is attached to the mail making the mail untransferable

Categories

(Thunderbird :: FileLink, defect)

x86_64
Windows 10
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 793118

People

(Reporter: Heinrich.Hartl, Unassigned, NeedInfo)

Details

(Whiteboard: [support])

Attachments

(11 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

This bug was first observe with Windows 10, Thunderbird 68.8.0 and persists in 68.8.1. The larger picture shows the situation after trying to send the mail: uploading the large file was completed and the link shows up in the mail. And this is the first hint for a malfunction I get a warning that my mailserver might reject my mail due to size. The next, smaller picture shows that the mailserver really rejects the mail. I then tried to remove the appanded file from the mail - I could not do so...
I was asked to redo the test using the scroll down list next to attach to upload the file - same outcome, see third picture

Actual results:

see above text and screenshots . Unable to send the mail, unable to remove the attachment

Expected results:

tiny mail should be sent which has the link information in the body.

This pop up confirms the warning given in BugThunderbird-1_68.8.png
BugThunderbird-3_68.8.png was a test reproducing same problem but starting the upload using the scroll sown list next to attach

So you don't get the prompt?

While writing an email, just attach a large file and you will be prompted to choose whether you want to use file link, which will allow you to share a large file with a link to download it. Via this prompt you can select to use WeTransfer.

WeTransfer File Transfer Now Available in Thunderbird

Filelink for Large Attachements

Component: Untriaged → FileLink
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Whiteboard: [support]

Why do you think I didn't get a prompt? I wanted to make clear that I did even try both methods:

  1. Add attachment - wait for prompt confirm link - get confirmation (in bottom line + in Linktext inserted into the message body + in attach-box wetransfer logo) ==> pop up "may be too large..."
  2. choose link from scroll down list next to attach - choose wetransfer - select file - wait - get confirmation (same as under 1.) ==pop up "may be to large"
    Trying to send anyway ==> confirmation rejected by server.
    Sorry if my words and the screenshots were not clear enough.

(In reply to Heinrich Hartl from comment #4)

Why do you think I didn't get a prompt? I wanted to make clear that I did even try both methods:

  1. Add attachment - wait for prompt confirm link - get confirmation (in bottom line + in Linktext inserted into the message body + in attach-box wetransfer logo) ==> pop up "may be too large..."
  2. choose link from scroll down list next to attach - choose wetransfer - select file - wait - get confirmation (same as under 1.) ==pop up "may be to large"
    Trying to send anyway ==> confirmation rejected by server.
    Sorry if my words and the screenshots were not clear enough.

Thanks for the clarification.

The error messages appear to indicate that the file is to large for the server to accept. Is that correct?

What is their server limit for file attachments?

I had no trouble sending a 51.5 MB file using WeTransfer via filelink.

Flags: needinfo?(Heinrich.Hartl)

I want to report the result of another test:
I used a 9MB file for the test.
write message
attach 9MB file
<< bottom line pops up recommends linking>>
push button to link the file
<< after a while I get confirmation about linking that file in three place - bottom line, link information in message body and wetransfer logo in attachment box.
send
<< message is sent properly and reaches recipient >>
however the message is large 12MB
the sent mail includes the attachment!
The recipient can both extract the attachment from the message and download it from wetransfer using the pfovide link in the body of the message...

Flags: needinfo?(Heinrich.Hartl)

Sorry, I can't reproduce any of the problems you are reporting and don't see a bug here.

Try Thunderbird Help

may I ask you about details of your test to reproduce the bug?
My latest test included

  • deinstallation of Thunderbird 68.8.1 from the windows 10 laptop
  • reinstallation Thunderbird 68.8.1 on the windows 10 laptop
  • sending another mail with a 9-GB Fileattachment linked to wetransfer

everything looks good but the attachment is not removed from the message (which is 12MB...) despite the link information is properly included.

Btw.: my emailprovider imposes a 32MB limit on sending mails (~50MB messagesize). This explains the sending failures wit the 55MB and 70MB attachments.

Flags: needinfo?(wls220spring)

Btw,: I do not have these problems on my ubuntu 18.4 laptop with thunderbird 68.7.0... After linking an attached file to wetransfer it is nolonger part of the email message.

while the first tests were made with an attachment larger then the server imposed limit (32MB) the later Test uses an attachment of 9MB. The malfunction is that the link to wetransfer is properly done the file is nevertheless also transferred within the email message bringing the latter to a size of 12MB.

Attached image filelink.png —

I see a link in the email and a 0 byte file in the attachment pane in both 68.8.0 and after updating to 68.8.1 on Windows 10.

The same using 68.7.0 on Ubuntu 18.04.4 LTS.

Flags: needinfo?(wls220spring)

sorry 915575 was the wrong attachement - I guess this one is better.

(In reply to Heinrich Hartl from comment #10)

Created attachment 9151575 [details]
wetrans.html documents a mail that includes both wetransfer-linked and attachedfile

while the first tests were made with an attachment larger then the server imposed limit (32MB) the later Test uses an attachment of 9MB. The malfunction is that the link to wetransfer is properly done the file is nevertheless also transferred within the email message bringing the latter to a size of 12MB.

Hi Walts58, your message looks good. The bottom line has the size 0 for the attachment and thats the difference. My messages retain the filesize despite successfully linked :-(
And that is so even after deinstalling TB and reinstalling it.
So status is you cannot reproduce my bug and I do not know how to correct the misbehaving TB an my laptop.

Another test seems to narrow the bug area:
I repeated my previous test with the 9MB attachment but I changed the residence of the file attached. In my previous test the file resided on a nas-device and smb was used to access the file on that device. For the repeated test I copied that file to the local HD. And the bug is gone, TB behaves perfectly... The attached file is linked and no longer part of the email-message.

(In reply to Heinrich Hartl from comment #14)

Another test seems to narrow the bug area:
I repeated my previous test with the 9MB attachment but I changed the residence of the file attached. In my previous test the file resided on a nas-device and smb was used to access the file on that device. For the repeated test I copied that file to the local HD. And the bug is gone, TB behaves perfectly... The attached file is linked and no longer part of the email-message.

Thanks for that update.

Unfortunately I can't test that setup.

Two more test seem to confirm that the bug can be reproduced and is not associated with a specific machine.

I used another client laptop for the test. Previous test used a Dell E5440 (newly installed in 2019) with Windows 10 and Thunderbird 68.8.1 - now I used a Lenovo Yoga also with Windows 10 and Thunderbird 68.8.1. The now used Yoga has a longer live since it was installed approximately fife years ago.
I composed a mail with an wetransfer-linked attachment > 2MB. Sending the mail was successful but the message body again included the link-attached file. I.e. The bug is reproduced with a different client laptop.

I used a different smb/nas-server. As already reported before I observed that the bug does not show when the attached file is residing on the local HD. But in all my tests so far the link-attached file was residing on my QNAP NAS-device. Now I configured a file-share on above mentioned Lenovo-Yoga.
Back on my Dell E5440 Laptop I repeated my test: composing a mail with a link-attached file. The difference is that I attached a file found on the network share provided by the Yoga machine. Sending the mail was successful but the message body again included the link-attached file. I.e. The bug is reproduced with a different network file server.

I reported on two test scenarios - just use another laptop to provide a network share (from which to select the attachment). There is no need to hava a dedicated nas device to reproduce the bug...

Flags: needinfo?(wls220spring)

(In reply to Heinrich Hartl from comment #17)

I reported on two test scenarios - just use another laptop to provide a network share (from which to select the attachment). There is no need to hava a dedicated nas device to reproduce the bug...

Sorry, I'm a Linux user and only have Windows 10 laptop.

Not interested in learning how to connect the two of them for testing.

Somebody else will have to confirm the bug.

Flags: needinfo?(wls220spring)

I have reproduced the bug using a network shared file residing on a Windows 10 64-bit virtual machine. This is on Thunderbird 68.8.1 64-bit on Windows 10 64-bit. The file itself is a 26MB executable for TeamViewer setup, which exceeds Gmail's attachment size limit of 25MB. In the first attempt, I had Thunderbird configured to save drafts in the Gmail account's Drafts IMAP folder. When I attached the network shared file using the file link option, the linking completed successfully and the WeTransfer link appeared in the message body as expected, but the attachment remained a regular attachment instead of getting converted into a WeTransfer attachment. I tried to save the draft, which expectedly failed and the Gmail server returned an error saying it could not copy the message to the Drafts folder because it exceeded the size limit.

On second attempt, I configured Thunderbird to save drafts in a local folder, linked the network file in a new message using WeTransfer, then saved the draft. On third attempt, I linked the file from the local Downloads folder, then saved the draft. The attachment in this case was replaced by a 0 (zero) byte "Attached Message Part" and the draft was a mere 5.9KB compared to the other drafts which were 35.7MB each. Thunderbird treated the attachment as a regular attachment despite having linked the file successfully using WeTransfer. Hovering the mouse pointer over the remotely stored attachment reveals a path to the %TEMP% folder where the remote file is copied to during the file linking process, so technically, the file is getting attached from local storage, but Thunderbird doesn't process it the same way it does a locally linked file. This is definitely a bug. The remotely stored attachment is not getting removed from the message and replaced with a zero-byte part despite being file-linked successfully.

Thank you very much Stans,
this is a important step forward, the bug is reproduced. This is the endpoint for my efforts to improve Thunderbird and to make it a highly reliable and comfortable tool. This is my endpoint because code change is beyond my capabilities.
Regards Heinrich

Hallo, two other people have reproduced the bug - I think status should be changed to confirmed.
Please dont be frightened by the long story - just look at the end: The failure is associated with attaching a large non-local file. That was not clear from the start.

Flags: needinfo?(contact)

Common Thunderbird Devs...
This problem is now over 8 years old...
https://bugzilla.mozilla.org/show_bug.cgi?id=793118 is the same problem.

Please fix this nasty bug ASAP.

Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: