Closed superlinuxero closed 7 months ago
Please clarify:
reported in Bugzilla by others and myself
Where?
fixed by you in Betterbird but present again in Betterbird 115
When, how? And
After some seconds the file is deleted from its temporary location.
How so, who deletes?
All that said, it looks like https://bugzilla.mozilla.org/show_bug.cgi?id=1873023, especially when you look at the commit message:
https://hg.mozilla.org/comm-central/rev/e560e091dbef
Would you like a version that includes this fix to test it?
Hi and thanks for your quick reply
Please clarify:
reported in Bugzilla by others and myself
Where?
Buff, I reported it at least 3 years ago. Behavior was slightly different. Then file names were renamed with filename-n.ext where n was an integer
fixed by you in Betterbird but present again in Betterbird 115
When, how? And
Don't know. Switched to BB at version 102 and it was running perfectly, while TB wasn't.
After some seconds the file is deleted from its temporary location.
How so, who deletes?
I suspect Betterbird does.
All that said, it looks like https://bugzilla.mozilla.org/show_bug.cgi?id=1873023, especially when you look at the commit message:
https://hg.mozilla.org/comm-central/rev/e560e091dbef
Would you like a version that includes this fix to test it?
Yes I would. In fact, I was about to downgrade Betterbird to 102 before I read your response
Many thanks
Ignacio
All your answers are too vague. IIRC, there was a lot of messing around with attachment processing, and yes, BB 102 had some advantage over TB 102. In the end, BB and TB code were aligned again, like you see in 115.
What I don't understand about the bug is this: When you drag an attachment from a received message to a composition, it noted the original mailbox or IMAP URL, as you can see when hovering the attachment in the composition. Haha, at least, that's how it worked. Now when you drag it, it already becomes a file in a temp directory. I wasn't conscious of that, the TB folks have changed too much in that area. So yes, than can conflict with viewing attachments before.
I'll make a version that includes the latest TB fix I mentioned within the next 2 hours.
For the record, the behaviour to put dragged attachments into a temp file was done here https://bugzilla.mozilla.org/show_bug.cgi?id=1760025 in TB 100 almost two years ago. So I'm surprised TB 102 was worse than BB 102.
Haven't tested it, I hope the TB folks did a good job. The code looks about right.
P.S.: You live close to Barcelona? Shout me a beer 😉.
P.S.: You live close to Barcelona? Shout me a beer 😉.
I live 400km south to Barcelona, near Valencia. Of course if you have the chance of dropping by contact me we'll have some beers for sure 😉😉😉
Yes I know my answers were vague. It's been a long time (sicne I started using BB) that I stopped worrying about my email program.
My initial tests with your build from today seem to fix the problem. Now it creates filename-n.ext in /tmp/pid-pidof thunderbird
for every interaction I do with the file (open, drag'n'drop), just as it did before BB in version 102 (TB 102 and some prior versions did the same but in some situations it wouldn't create the file with the -n annex at the end of the filename)
Now it would be a good idea that TB/BB would delete that tmp folder when closing the program. Right now it leaves the /tmp folder plenty of garbage from previous sessions. Maybe I should open a request at Bugzilla...
ignasi@hal:/tmp$ ls -ld /tmp/pid-*
drwx------ 1 ignasi ignasi 438 ene 9 11:47 /tmp/pid-112996
drwx------ 1 ignasi ignasi 2012 ene 10 12:33 /tmp/pid-159076
drwx------ 1 ignasi ignasi 156 ene 10 13:44 /tmp/pid-837052
drwx------ 1 ignasi ignasi 206 ene 9 11:40 /tmp/pid-8522
drwx------ 1 ignasi ignasi 586 ene 10 16:52 /tmp/pid-961753
ignasi@hal:/tmp$
Thanks so much for your help. You are great!
Our office is north of Barcelona on the Maresme coast, check the "Aviso legal" on the website. I saw "Maresma" in your video.
Yes, please file a follow-up to https://bugzilla.mozilla.org/show_bug.cgi?id=1760025 and https://bugzilla.mozilla.org/show_bug.cgi?id=1873023 like so:
Summary: Temporary directories left behind from composing with dragged attachments
When adding at attachment from another message, this is store in the temp directory in a folder pid-NNNN. The code registers the file itself for deletion here: https://searchfox.org/comm-central/rev/d47e431b702099ec3bbfa8a8fffe0060d4823497/mail/components/compose/content/MsgComposeCommands.js#7977 but the directories are left when TB closes.
Yes, please file a follow-up to https://bugzilla.mozilla.org/show_bug.cgi?id=1760025 and https://bugzilla.mozilla.org/show_bug.cgi?id=1873023 like so:
Done. Thanks again for your help!
We've fixed the bug you filed https://bugzilla.mozilla.org/show_bug.cgi?id=1873950 and will ship the fix in the next release: https://github.com/Betterbird/thunderbird-patches/blob/main/115/bugs/1873950-delete-temp-pid-NNNN.patch
Hello and thanks for your efforts!
The main reason I moved from TB to BB was a bug in TB that hasn't been fixed for ages (reported in Bugzilla by others and myself), fixed by you in Betterbird but present again in Betterbird 115 (at least in Linux). Let me briefly explain.
When opening a PDF attachment with my favorite pdf reader, a copy of the file is temporarily created at /tmp/pid-n where n is the pid of Betterbird. After some seconds the file is deleted from its temporary location. If then I compose a new message and drag and drop the attachment when sending Betterbird complains the file isn't available since the file isn't available in its temporary location anymore and no additional copy was created when dragging the attachment to the compose window.
I've made a quick video showing this behavior: https://youtu.be/phdnIiUcBuo