Thunderbird and Seamonkey leaves behind files in [%TEMP%] folder
nscopy-*.*, nsemail-*.*, nsmail-*.*
They are drafts, pictures, and other stuff that were opened, copied.
New: Kanri (Oct 9, '24), Platform 29.5.3 (Jun 27, '24)
1,100+ portable packages, 1.1 billion downloads
No Ads November!, Please donate today
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
If you open something from Seamonkey or Thunderbird in another program and close SM/TB before closing whatever you opened it in, it can't delete it.
Sometimes, the impossible can become possible, if you're awesome!
I was just editing a draft
I copied an image from irfanview after resizing it and pasted it to the draft.
Only copying and pasting images and urls, then saving the draft
And, still the temp files remain.
I do not see any reason it should keep temp draft files after shutdown in any case. As it does not depend on other programs
because when you copy and paste it save it to the clipboard which is the temp folder
SO pictures etc are in temp folder for pasting back. Instead of copying picture try saving it first then inserting it. Also afaik once you reboot system temp file should clear itself as far as the clipboard is considered
“Be who you are and say what you feel because those who mind don't matter and those who matter don't mind.” Dr. Seuss
But the whole email draft is also saved in temp folder ( the draft containing the images) and is not removed on closure.
Once this draft is saved, it should not have any locks on it anymore, as it is already closed ( saved ).
So, when I exit seamonkey or thunderbird the draft should be erased.
I do not see how urls and photos in clipboard can cause a lock in an email draft.
The drafts should not be left behind.
They should be erased before SeamonkeyPortable.exe exits.
the paste function in reality is nothing more than a fancy pointer to the temp folder where it has to retrieve the clipboard information. and if the file still looks for it in temp the temp folder still needs to exist. Sort of the same as the temp folder in any browser. AFAIK the only work around is to not copy and paste the graphics but to save the graphic then point it to the file instead of the clipboard
“Be who you are and say what you feel because those who mind don't matter and those who matter don't mind.” Dr. Seuss
Could you try using this ThunderbirdPortable.exe launcher and confirm whether it fixes your issue? Just replace your existing ThunderbirdPortable.exe with this one. If it works, I'll rebuild Thunderbird 12.0.1 and release it with this.
UPDATED (7:42pm NY time on May 1): Updated to 1.7.2 to better handle other possibilities. This should handle it completely. Please confirm.
Sometimes, the impossible can become possible, if you're awesome!
This is fixed with the release of SeaMonkey 2.9.1, Thunderbird 12.0.1 and Thunderbird ESR 10.0.4 Rev 2.
Sometimes, the impossible can become possible, if you're awesome!
Seamonkey 2.10 | 2.10.1 leaves behind folders
in AppData\Local :
Mozilla\SeaMonkey
That's a different issue than this (read that it's TEMP files that were affected in this bug). We're looking into the issue you mentioned as it appears to affect all mozilla apps.
Sometimes, the impossible can become possible, if you're awesome!
Different issue, same concept
Just thought better update this thread than creating a new one with same subject [ Temp files left behind ]
Regarding the files you posted,
I just tried version 1.7.2 (as I did not have time before, and I switched to seamonkey for a while)
And, I believe folders are left behind in
AppData\Roaming\Mozilla\Extensions
It did not leave anything behind in appdata/local, though
Whereas, seamonkey's new verion leaves behind folders at
AppData\Local :
Mozilla\SeaMonkey
Yes, but it's a different bug due to different reasons. Lots of things leave files behind. So, it's not this bug, this bug is closed. We're looking into how the mozilla rendering engine changed as this affects all 3 mozilla apps.
It's covered in Bug 33472.
Sometimes, the impossible can become possible, if you're awesome!