528377 - jpg attachment can not be replace by file of the same name

Status: RESOLVED DUPLICATE of bug 404922

(Thunderbird :: Mail Window Front End, defect)

Description

[James]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; hc; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Build Identifier: 2.0.0.23

The bug is if I drag a jpeg file into an email to the attachment window and then decide to delete it from the attachment list and drag a new jpeg in with the same name it doesn't take the new jpeg but replaces it with the old jpeg. That's bad. 

Reproducible: Always

Steps to Reproduce:
1. drag jpeg to attachment panel
2. delete jpeg
3. create new jpeg with same name. 
4. Drag new jpeg to email. It reattaches old jpeg and won't take new version. 



I would expect it to forget the deleted attachment and take the new version.

Comment 1

[rsx11m]

If you would use the Windows right-click Send To > Mail Recipient I'd say this is bug 356808, but since you are using drag-and-drop instead, this may be a special case of bug 404922. That bug is on dropping the image into the message body though during composition, whereas the report here indicates the same happening also with "true" attachments. The mechanism involved may be the same.

Comment 2

[rsx11m]

I'm unable to reproduce this with either 2.0.0.23 on Windows or current nightly builds. How did you "create new jpeg with same name" exactly? For testing, I've renamed existing files so that they matched the same name when attaching, the most recently renamed file was selected (which is what I would expect to happen, given that only a reference is noted during the attaching procedure and then resolved when sending).

Was your message saved as a draft before reattaching? Or, did your second file come from a different location/folder and just had the same name?

Comment 3

[James]

I'm very sorry, I got confused. It was inded happening where I was dropping the message into the body of the email, not the attachments area. I was doing both. 

I'm very glad to see you are already aware of that case in bug 404922. Again sorry for the imprecise reporting. I know the bug has been around for a while since I've run into it many times, but I just discovered the reporting area which is great. I didn't know that the appropriate image would be resolved and sent regardless of what is displayed while editing. It's still a little disconcerting though when editing technical reports where I might be refreshing inserted images several times to get them right. I appreaciate very much your speedy research.

Comment 4

[rsx11m]

No problem, I'm resolving this as a duplicate then.