User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 SeaMonkey/2.39 Build ID: 20151103191810 Steps to reproduce: Browsing with SeaMonkey 2.39 (US and DE) on Windows 7 x64 english and german Actual results: Browser is configured to clear the Cache when SeaMonkey is closed. Cache Folder Location is default folder. Setting a maximum usage for disc cache does not affect the problem. Within the directory C:\Users\$User\AppData\Local\Mozilla\SeaMonkey\Profiles\xxxxxxnn.default there are currently 115 Cache.Trashnnnnn (n=random number) these folders contain cache files and folders of older sessions. There are about 75000 folders containing 8500 files (~2GB) on my disc right now. For each session there is a new folder. Clearing the cache with the button in preferences/advanced/cache does not delete the cache.trash folders. Expected results: Cache files should not remain on disc.

(In reply to hallobox from comment #0) > Browser is configured to clear the Cache when SeaMonkey is closed. Where and how?

Preferences/Privacy&Security/Private Data/Clear Private Data is set to "Always clear my private data when i close SeaMonkey". Cache is selected, only saved passwords an my location bar history are not erased.

I did a test 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: Indeed the cache

I did a test 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: Indeed the cache folder is not completely empty after SM has been closed with preferences due to comment 2. But the function only is for deletion of private data, not for wiping out all contents. @reporter: any indications that a) private data has been left b) current behavior is not in accordance with Help or technical rules or specifications or anything else?

a} Content of files unknown (no extension) didn't look into them, file names are random. How does the browser decide which files contain private data? b) The main issue is the cache management. A size limit for cache files set in Preferences/advanced/cache is not recognized by the browser. If i set a limit of 50 MB and there are 2GB of cache.trashnnnnn folders on my disc, something is wrong. Nochmal (ausführlicher) auf deutsch: a ) Wenn ich (als Anwender) dem Browser sage, er soll meinen Cache beim Beenden löschen, dann erwarte ich, dass er das auch tut. Er soll die Daten nicht aufbewahren bzw. Trash-Ordner daraus machen. Wie will der Browser entscheiden, welche Daten relevant, sprich löschens- oder erhaltenswert sind? Es geht mir hier jetzt nicht primär um irgendwelche Privatsphärenprobleme. Wer solche Sorgen hat verwendet andere Systeme. b) Vor der aktuellen Version, zumindest bis 2.33?, hat mir der Browser nicht die Platte mit den Cache.trash Ordnern vollgemüllt, er hat die Dateien entsorgt. Das kann ich in den alten Backups sehen. Ich musste auf meinem Zweitrechner über 100.000 Ordner von der Platte putzen. Darin waren fast 8GB Datenmüll. Allein das Löschen von derart vielen Ordnern dauert unter Windows etwas länger. Von Dateisystemchecks will ich jetzt nicht anfangen, die brauchen dann ja Tage. Lange Rede kurzer Sinn: Wie schaffen wir es, dass der Browser seine "Altdaten" auch wirklich löscht? Oder aber das eingestellte 50MB-Limit für Cache-Dateien berücksichtigt? Papierkörbe bringen ja keinen weiter.

The categories of so-called "Private Data" that a user may opt to clear (or not) at every closedown are the following: • Browsing History • Location Bar History • Download History • Saved Form and Search History • Cache • Cookies • Offline Website Data • Saved Passwords • Authenticated Sessions • Session Manager Saved Sessions Some of the above may be due to extensions I have; but I'd say that finding out that there are 2 GiB of leftovers due to not having cleared the cache that the user asked to clear is, er, shall we say "unexpected"? It could be explained, however, if SeaMonkey was not "properly" closed every time. What I call "proper" closing consists of: 1. Hit Ctrl+Q or use the "File → Quit" menuitem. 2. Wait, maybe several minutes even after the last SeaMonkey window disappears, for the seamonkey.exe (Windows) or seamonkey (other platform) process to terminate completely. While you wait, you can open the Windows Task Manager (when I was on Windows XP SP2 it could be accessed from the Ctrl+Alt+Del menu) or, on Linux, the KDE System Guard or the Gnome System Monitor, or on the Mac whatever corresponds to them; and watch the graphical use of memory and CPU. After you hit Ctrl+Q in SeaMonkey, its memory use may go a little up, then a little down, then stay there some time, then go down a lot, possibly in two or three steps. At that moment, open the Preocesses tab and sort the processes Z to A on the process name without asking for a tree. If SeaMonkey is not present at its reverse-alphabetical place, then it has really closed. Of course, if it is still present, then it hasn't yet completely closed. The following procedures DO NOT close SeaMonkey properly and might kill it before it has the time to do all the desired cleanup: (a) Clicking the [X] button at the end of each of its windows' titlebar; (b) (even worse) Closing down Windows (or logging out of X11 on Linux, or closing down Mac OS X) while SeaMonkey is still running; (c) Hitting Ctrl+Q on SeaMonkey, but then proceeding to close down the OS without first making sure that SeaMonkey has finished closing down.

>It could be explained, however, if SeaMonkey was not "properly" closed every time. SeaMonkey was properly closed. No process visible in Windows Task Manager after about half a second. I don't tend to "kill" my apps. A hint for reproducing this issue: After using SeaMonkey for only 5 Minutes everything is fine. Cache folder gets cleared (8MB while using, 88K after closing). But the already existing cache.trash folders remain on disc. But if you keep using the same session for lets say 2 hours straight, you may see a new cache.trash folder after closing SeaMonkey. For example: I've got two new cache.trash folders with timestamps of 5:38pm and 7:01pm. So here is another question: Why/in what situations does SeaMonkey create cache.trash folders?

The "Cache folder not empty after 'When Quit Clear Private Data - Cache'" proceeding is rather unpredictable. 1. After at least ¼ hr. using SM browser with at least 50 TABs having been opened and several of them colosed again: menu 'File → Quit' 2. Wait until SM is no longer visible in Task manager 3. Check <C:\Users\user\AppData\Local\Mozilla\SeaMonkey\Profiles\<yourporfile>\: rightclick on "Cache" folder → Properties » in very few cases folder will be completely empty (no folders, no files) » Most times I see lots of folders and 4 files: _CACHE_001_, _CACHE_002_, _CACHE_003_, _CACHE_MAP_ Bug: I these files I find hyperlinks to pages I visited, images what have been loaded and other browser session related hints what should have been deleted I will do additional tests concerning Profile- and add-on- dependency later the cache.trash - issue should be examined in a separate Bug report.

REPRODUCIBLE 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 with clean new profile. Using SeaMonkey browser for a while with preferences due to Comment 2 creates a folder <C:\Users\user\AppData\Local\Mozilla\SeaMonkey\Profiles\<yourporfile>\ In this folder mentioned 4 files will remain with session data although private data should be deleted. Additional information: e) SM 2.33.1 did not use a cache folder, so this one is a new problem e1) I did not yet test with what version the problem appeared f) situation was not better with 2.33.1, there "cache2" was used, and there also lots of files remained with session data. f1) "cache2" still is used, I did not do detailed tests what for. g) Currently it seems to be unclear for most users how SM browser cache works. can someone leave some hints at <https://wiki.mozilla.org/SeaMonkey/Help#Browser_Cache>?

k) Still REPRODUCIBLE 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

"Bug 1234053 - After 'When Quit, Clear Private Data - Cache' a folder "Cache.Trash____" remains" is a follow-up ot this one.

h) OS = ALL due to Bug 1234053 comment#9

Testing with a fresh profile (no preference changes) and having the same settings for Private data as in comment 2 (and not to ask at the exit), I can see we delete individual files but not all stuff from all blockfiles (the _CACHE_00*_ files). The old cache code is no longer maintained and should not be used at all these days for caching common HTTP content. No one on the platform team is going to invest a cent of time to find out what's happening here, unless SM is switched to the new cache backend. Filed bug 1241622 on it. However, quick tests with SM, cache2 and setting from comment 2 shows the problem might persist anyway. What I see is that cache is cleared (the cache2/entries is renamed correctly to cache2/trash.xxxx) but we don't wait for it to be deleted before real exit. Problem is apparently in two things inside SeaMonkey: - I don't see the preference "privacy.clearOnShutdown.cache" be set to true (precondition to delete the cache before shutdown) - SM is probably trying to clear the cache itself during shutdown and don't use the proper sanitization settings as other end products based on Gecko (I guess) Definitely a SeaMonkey bug.

> the _CACHE_00*_ files It is expected that they are physically there after clearing the cache. It is also expected that they should have no meaningful data within, (should be null filled $00$). (I'd assume they're deleted & recreated, "empty", but I didn't check to confirm.) > cache2/trash.xxxx I have seen that - sometimes, & that is a bug. (Don't know STR, consistently?) If files are left within the 0-F directory trees, then that too would be a bug. (I looked at this a while back now, & don't exactly recall just what I saw, but trash.xxxx did happen, sometimes.)

(In reply to therube from comment #15) > > cache2/trash.xxxx > If files are left within the 0-F directory trees, then that too would be a > bug. There are a lot of files left. Sometimes thousands of them. --> Screenshot http://www.hallobox.de/bug.jpg On Win7Pro the trash.xxx folders are not within the cache2 folder.

The first half of the screenshot shows 12 MB of "space" being used. And you can see that 4+4+4 MB + 9 KB. That those files exist is immaterial - so long as their contents are null. Likewise, from what you've shown, you don't know the size of the 0-F directories, but given the size in its entirety is 12 MB, & the 4 files that you can see are essentially 12 MB, that would leave one to believe that the contents of 0-F are just about 0, which if you've cleared cache, that is what they should be. And if instead of selecting the Properties of /cache/ itself, if you highlighted 0-F & checked their Properties, I would expect it would show 0 bytes. --- > There are a lot of files left. Sometimes thousands of them. Yes, & that deals with Cache.Trash####. Cache.Trash#####, for whatever reason it ends up being, is what it is & contains what it contained at the time it was kicked out. That indicates something, whatever it might be, went wrong. The state of things as it was is what you see. "Clearing cache" will not affect & is not expected to affect (well AFAIK) any Cache.Trash####. If you're aware of their existence, & you have no need for them (like why would you), you can delete them (yourself, manually). --- Now if after clearing cache, if files other then the four _CACHE_* are left in the /cache/ 0-F directories, or if the _CACHE_* files actually contain relevant data, then that would be a bug. (And from what I recall, that can & does occur - sometimes, when clearing cache on Quit.)

(In reply to therube from comment #17) > The first half of the screenshot shows 12 MB of "space" being used... Correct, the left side of the picture shows the "clean" cache. On the right side of the picture is the cache content after closing down SeaMonkey. > "Clearing cache" will not affect & is not expected to affect (well AFAIK) > any Cache.Trash####. Correct. Problem is, manually deleting these folders on Windows is time-consuming. On a PC where i can delete these folders only once a week, it takes up to 10 minutes. There were about 30K files/120K folders in Cache.trashxxx-folders. > Now if after clearing cache, if files other then the four _CACHE_* are left > in the /cache/ 0-F directories, or if the _CACHE_* files actually contain > relevant data, then that would be a bug. (And from what I recall, that can > & does occur - sometimes, when clearing cache on Quit.) As Rainer mentioned in Comment 8, it happens sometimes. Quick question: Why disk-cache at all? If user setting is to delete all that stuff on closing, why not store this stuff in ram?

No $Trash-folders anymore in Version 2.45 (Adrian Kalla) User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 SeaMonkey/2.45 Build identifier: 20160905081108 _CACHE_001_, _CACHE_002_, _CACHE_003_, _CACHE_MAP_ still contain session data after closing SM.

Ok, sometimes there still are those folders. Browsing an imageboard for about 20 minutes an loading ~30 images into tabs does the job.