This one is a follow-up to "Bug 1233744 - Cache folder not empty after 'When Quit Clear Private Data - Cache'". Steps how to reproduce with SeaMonkey German 2.39 final Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0 from official download area) Gecko/20100101 Firefox/42.0 Build 20151103191810 (Classic Theme) on German WIN7 64bit: 0. In C:\Users\user\AppData\Local\Mozilla\SeaMonkey\Profiles\<yourporfile>\ delete al folders with names starting with "cache" 1. Launch Browser 2. Menu 'Edit → Preferences → Privacy & Security → Private Data: Check "Aways clear when close", Ask me ...", "Cache"' 3. Work 1/4 hour, open at least 50 different TABs, leave 10 or more open 4. Menu 'file → Quit', confirm Cache deletion when asked » SM will be closed 5. When SM has vanished in Task manager, check <yourporfile> » unexpectedly a folder "Cache.Trash12345" (or similar) has been created Bug: At least Files _CACHE_001_, _CACHE_002_, _CACHE_003_ will contain private session data.

NEW due to Bug 1233744 comment #0, Bug 1233744 comment #5

Additional information a) My tests showed that this behavior is not related to existing user profile or add-ons.

Hallo Rainer! You don't have to open more than a single tab. I have been experimenting with this a bit through the night and still got the above mentioned behavior when i used SeaMonkey without additional tabs. It does not matter if there is/was a mail window during the session. Session runtime also doesn't seem to be a factor. I could reproduce the issue within 5 minutes once, did nothing special, just browsing an online shop. As far as i can tell it makes no difference how you are exiting the last SeaMonkey window. I got a new cache.trash folder after exiting with Ctrl+Q and once when i just closed the browser with "X". I checked my mothers computer today and found a lot of cache.trash folders (about 140) as well. She always closes every application by using the main menu. User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 SeaMonkey/2.39

Hm. I seem unable to reproduce the problem in SeaMonkey 2.43a1 for Linux64: UA:"Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0 SeaMonkey/2.43a1" ID:20151217003002 c-c:c7fb0822b04746fcb1321ab430a471160459e20c m-c:0babaa3edcf908c393b68a3dc2d1c2a2450c31ed en-US I closed SeaMonkey with "Clear Private Data: Cache" as mentioned in comment #0 (after previously having browsed with no clearing for I don't know how many sessions) and once the seamonkey process had disappeared no file or directory named cache* or Cache* could be found in my profile (on Linux, filenames are case-sensitive). However, I have more RAM than I need: Currently I'm using 5.0 of 7.7 GiB of RAM, and zero bytes of 19.7 GiB of swap space. I have 347 tabs open, about:cache says I'm currently using 101997 KiB of disk cache at ./Cache in my profile, but a directory listing of my profile, even with "show hidden files", displays nothing of the sort. I suppose the cache buffer hasn't yet been written to disk. I'll keep watching for any symptoms.

Also FF 45.0a1 (2015-12-09) createds these Cache.Trashxxxxx folders

After a long session, and exiting without clearing the cache, there is still no cache file in my profile. The difference could any (or several) of Linux vs. Windows, or 2.43 vs. 2.42, or 32bit vs.64bit (WOW64 means a 32-bit program on a 64-bit Windows OS), or even RAM availability...

(In reply to Tony Mechelynck [:tonymec] from comment #6) > no cache file in my profile. Thank you for testing, I will do some own Linux tests later.

(In reply to Tony Mechelynck [:tonymec] from comment #6) Is the Linux profile also parted into a Local and Roaming area?

I followed instructions at <http://kb.mozillazine.org/Profile_folder_-_SeaMonkey> and was able to reproduce observations of "Bug 1233744 - Cache folder not empty after 'When Quit Clear Private Data - Cache' " with SeaMonkey 2.42a1 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0 from public download area) Gecko/20100101 Firefox/ 45.0 Build 20151111021032, (Classic Theme) on German WIN7 64bit. but no "Cache.Trash" folders found. In a different profile, until now not used for tests for this bug, I found 2 older folders Cache.Trash1444091466 and "Cache.Trash1973880435". What ever this might mean.

It seems that Bug 1233744 comment #13 is concerning the reason why this one has been considered as a DUP of bug 1233744 (I don't understand all details).