Attachment Troubles - Frequently Opening the Wrong File with the Same Name
Categories
(Thunderbird :: Untriaged, defect)
Tracking
(Not tracked)
People
(Reporter: daniel.prochazka, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/117.0
Steps to reproduce:
-Colleagues send me various files for printing at the airport.
-When they drag and drop a specific file into the email attachment, which I should print, a different file is sent, which is stored on their PC somewhere (in a different folder) with the same name.
Actual results:
I receive the wrong file, which they did not drag and drop. This issue started after updating to Thunderbird Supernova 115.
Expected results:
The correct file that they dragged and dropped into the email attachment should have been inserted, regardless of the fact that the same file with the same name is stored somewhere else on their PC in a different folder. This issue occurs intermittently and represents a significant security concern. Currently, both my colleagues and I have to save all attachments to our PCs and rename each file to ensure it has a unique name and is not stored anywhere else on the PC.
|
||
Comment 1•1 year ago
|
||
I don't see how Colleague sending the wrong attachment is Thunderbird's fault, unless Colleague is also using Thunderbird.
|
Reporter | |
Comment 2•1 year ago
|
||
Yes, colleagues also use Thunderbird Supernova 115.
|
|
||
Comment 3•1 year ago
|
||
other reports https://mzl.la/3F5iOIe
|
|
||
Updated•1 year ago
|
I tried to replicate.
Tested beta 119.0b6
Two image files one a cow and one a chicken both named 'chicken 1.JPG' stored in two different folders.
'Hold' on desktop contains the 'cow' and it has a subfolder also called 'Hold' which contains the chicken.
Created emails with same subject and sent from a gmail account to a another account on a different server.
Sent two separate emails and used drag and drop to 'attach' files (not inline).
Both emails received and one has a chicken and one has a cow. So there is no confusion in just 'attaching' different files with identical name.
I opened each using Windows Photos and noted each time I opened either of those files it created a new instance of image and had a name which updated the number because each opening of the files was stored as a new temp file in same location. Windows auto updated the temp saved file name because it was identical.
eg: 'chicken 1.JPG', 'chicken 1-1.JPG', 'chicken 1-2.JPG' , 'chicken 1-3.JPG' etc
The image files were being stored in single pid folder called : 'pid-5288' in .../Appdata/Local/Temp folder
That pid folder will never be deleted unless I do it.
I also tested this sending and receiving in both directions between the beta 119.0b6 version and the 102.15.1 version.
Results: I'm not able to replicate this bug.
Q: But what does the bug reporter see in their Appdata/Temp file ?
Q: Do they see the same name files in a pid folder ?
Q: Is their computer set up to auto increment name with number ?
Naturally, you cannot rule out that the sender got it wrong which is probably very easy to do if the file name is always the same.
Maybe, the file is one that is constantly reused - edited?
In which case it is very easy to send an older file if the edited version has not been saved and closed first.
|
|
Reporter | |
Comment 5•1 year ago
|
||
Hi,
Thank you very much for the response. It still doesn't work for me, but only occasionally, and it's a mystery to me why it only happens occasionally. I don't know what is causing it.
A more serious issue is the long time it takes to open email communications from attachments. I have discussed this with my 7 colleagues in the office, who have version 115 and above. Some emails take up to 4 minutes to open, and some don't open at all. The Thunderbird application fails and closes.
For us, it is very important because when I receive an email conversation from another department as an attachment, I try to respond to it, but it doesn't always open. And when it does open occasionally, it might take up to 4+ minutes.
It's frustrating.
Because of this, I directly tell my colleagues not to send email conversations as attachments. Instead, I ask them to forward those emails because they open normally that way.
|
|
Reporter | |
Comment 6•1 year ago
|
||
(In reply to Daniel Prochazka from comment #5)
Hi,
Thank you very much for the response. It still doesn't work for me, but only occasionally, and it's a mystery to me why it only happens occasionally. I don't know what is causing it.
A more serious issue is the long time it takes to open email communications from attachments. I have discussed this with my 7 colleagues in the office, who have version 115 and above. Some emails take up to 4 minutes to open, and some don't open at all. The Thunderbird application fails and closes.
For us, it is very important because when I receive an email conversation from another department as an attachment, I try to respond to it, but it doesn't always open. And when it does open occasionally, it might take up to 4+ minutes.
It's frustrating.
Because of this, I directly tell my colleagues not to send email conversations as attachments. Instead, I ask them to forward those emails because they open normally that way.
Working on 115.5.1.
Description
•