581515 - dragging attachment from received message to compose window can attach the wrong file

Status: NEW

(Thunderbird :: Message Compose Window, defect)

Description

[Mike Shaver (:shaver emeritus)]

The office scanner sends me my scans as PDF attachments, all called "image.pdf".  To send them on to other people, I drag the attachment to a new message, which usually works.

Sometimes, however, they get the wrong attachment: they get the image.pdf that is in my %TEMP%, which is often quite old (and, happily, so far not sensitive information).  I can't reproduce it reliably, but I've had it happen twice in the past two weeks.  I may in fact have had it happen more than that, but I'm only sure that these recent cases aren't user error, because I deleted the message that has the old image.pdf in it.

I go online/offline a lot, dunno if it matters.  I'm running 3.1, will try to reproduce it with Blake's help or at least patience.

Comment 1

[Thomas D. (:thomas8)]

Reminds me of the attachment handling design flaws as described in 378046, comment 60.

Comment 2

[Thomas D. (:thomas8)]

Or, it could be another instance of wrong attachment paradigm of "attach later when sending" (see tracker bug 877159), when auto-compact reshuffles messages and their ids which might then swap the content of attachment (similar to bug 766495).

Comment 3

[WADA:World Anti-bad-Duping Agency]

(In reply to Thomas D. from comment #2)
> Or, it could be another instance of wrong attachment paradigm of
> "attach later when sending" (see tracker bug 877159), (snip)

As for "attached FILE(not embed image in HTML mail) of an existent mail is Drag'ed to newly composed mail" case, I think different issue, although it may be resolved by improvements for bugs listed in that meta bug.

Quick chect with Tb 17.0.6 on Win-XP.
(0) An existent mail is multipart/mixed, and application/pdf part is contained(name = "日本語.pdf")
> --------------030205060309040601040305
> Content-Type: application/pdf; name="=?Shift_JIS?B?k/qWe4zqLnBkZg==?="
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment; filename*=Shift_JIS''%93%FA%96%7B%8C%EA%2E%70%64%66
(1) Attach by Drag #1, open atached file by Adobe Reader
(1-1) Compose a new mail #1, Drag the PDF attachment of (0)
(1-2) At attachement box of new mail #1, request Open
      => Adobe Reader is invoked.
　　　　　　　 File name=c:\Doc...\ ... \Temp\日本語.pdf
      Close Adobe Reader
(2) Attach by Drag #2, open atached file by Adobe Reader
(1-1) Compose a new mail #2, Drag the PDF attachment of (0)
(1-2) At attachement box of new mail #2, request Open
      => Adobe Reader is invoked. Suffixed as expected.
　　　　　　　 File name=c:\Doc...\ ... \Temp\日本語-1.pdf
      Close Adobe Reader
(3) Delete all files under %Temp% directory/sub directories by Command
    CD  %temp%
    DEL %temp%\*.* /S /F /Q
    RD  %temp% /S /Q
    ...\Temp\日本語.pdf and ...\Temp\日本語-1.pdf is deleted by command,
    because file is not locked.
(4) Save as draft at composition window #1 and #2
    => Draft save fails with following dialog.
       (UTF-8 binary of filename looks shown as Shift_JIS binary)
> ! Unable to save your message as draft.
>   There was an error attaching 譌･譛ｬ隱�.pdf. Please check if you have access to the file.
>    [ OK ]

Tb 17 on Win-XP looks to create "Snap Shot of attachment file in other mail" upon Drag&Drop, with adding suffix if same name is already used, almost as expected.

IIRC, Tb had problem like "Tb doesn't add suffix when same name is already used in %temp% directory or %temp%.\...\MAPI directory, instead Tb uses existent file". Such problem looks already resolved in Tb 17.

From perspctive of "attaching file at composng mail", this case is same as "attached file = existent ...\Temp\日本語.pdf(or 日本語-1.pdf)" case, and Tb perhaps holds pointer to file as "file://C:/　... /Temp/　... /日本語.pdf(or 日本語-1.pdf)". 
So, problem may be called "wrong attachment paradigm of attach later when sending", as you say.
But, even if Tb takes Snap Shot of the attached temp file, attaching file fails if the Snap Shot is deleted by other software.
In this bug's case, I think "lock temp file", or "lock Snap Shot File", is needed.

Comment 4

[WADA:World Anti-bad-Duping Agency]

Additional observation.
After above save error due to %temp"% file delete by other software, "save as draft by close composition window" successfully saved mail as draft, with correct attachment data.
I think this is because Tb knows original mailbox:// server+mbox+messageKey+partNo of attached file.
As you say, if original mail is deleted or moved or replaced, I guess problem of "wrong attachment paradigm of attach later when sending" will be exposed.

Comment 5

[WADA:World Anti-bad-Duping Agency]

"%temp% file use in Drag of other mail's attachmet" seems rather rare case.
(1) Drag&Drop pdf attachment of a mail in MboxA to compsing mail
(2) Save As Draft => nothing is created under %tmp% directory.
(3) Move all mails in MboxA to other Mbox, Compact MboxA,
    and Save As Draft
    => Following error dialog is shown.
> ! Unable to save your message as draft.
>   There was an error attaching 譌･譛ｬ隱�.pdf. Please check if you have access to the file.
>    [ OK ]
(4) Copy back referred mail to MboxA,
    with same messageKey as original(=Offset in my test),
    and Save As Draft
     => draft is normally save. Apparently milbox:// URL is used.

It looks;
(1) By Drag&Drop of attachment of existent mail,
    mailbox:// or imap:// URI is used
    => Problem due to no Snap Shot can occur
(2) If Open of attachment is invoked at composition window,
    and if it's opened by external application,
    Snap Shot is created under %temp% directory,
    and it's passed to application.
    Because Snap Shot is taken, file:// URL is used here after.
    => Problem due to interfere on tempby other software can occur.
(3) If access via file:// URL for temp file fails,
    Tb can fall back to original mailbox:// or imap:// URI.

Main problem in this bug is, as you say, wrong attachment paradigm of "attach later when sending".