http://bugs.winehq.org/show_bug.cgi?id=23876
Summary: Temporary Internet Files growing endless Product: Wine Version: 1.3.0 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mshtml AssignedTo: wine-bugs@winehq.org ReportedBy: diafero@arcor.de
It seems like applications using the embedded internet explorer will fill the Temporary Internet Files in my wine profile and make it grow endless: The game "Uru - The Path of the Shell" uses the embedded IE to download game updates. It runs perfectly fine in wine, but checking with a disk usage utility, I noticed that the Temporary Internet Files folder has a size of more than 600MB by now, containing a huge lot of the files that were downloaded by the updater (including the meta files with the update information that are downloaded on each startup - I had the same file in there more than 100 times). Obviously, the cache is not restricted by size as it is on windows.
http://bugs.winehq.org/show_bug.cgi?id=23876
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download CC| |austinenglish@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=23876
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|mshtml |-unknown
--- Comment #1 from Juan Lang juan_lang@yahoo.com 2010-08-02 13:42:57 --- Please don't guess the component, it's almost certainly not mshtml.
http://bugs.winehq.org/show_bug.cgi?id=23876
--- Comment #2 from diafero@arcor.de 2010-08-02 13:55:39 --- I thought mshtml is the component responsible for downloading files through HTTP and render HTML - I'm sorry if that caused any trouble.
http://bugs.winehq.org/show_bug.cgi?id=23876
Phil Hannent philip@hannent.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |philip@hannent.co.uk
--- Comment #3 from Phil Hannent philip@hannent.co.uk 2010-09-04 06:34:37 CDT --- I just noticed that with World of Warcraft Cataclysm beta 4.0.1 my home folder as lost 1GB of free space. From 3 hours of playing the beta.
The new beta downloads game files whilst you are playing the game. My current Temporary Internet Files is 165,355 items, totaling 12.9 GB. On 64bit ubuntu 10.04 using wine version 1.3.2 which was a fresh install 6 months ago.
http://bugs.winehq.org/show_bug.cgi?id=23876
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh@gmail.com
--- Comment #4 from Jerome Leclanche adys.wh@gmail.com 2010-09-04 07:06:38 CDT --- (In reply to comment #3)
I just noticed that with World of Warcraft Cataclysm beta 4.0.1 my home folder as lost 1GB of free space. From 3 hours of playing the beta.
The new beta downloads game files whilst you are playing the game. My current Temporary Internet Files is 165,355 items, totaling 12.9 GB. On 64bit ubuntu 10.04 using wine version 1.3.2 which was a fresh install 6 months ago.
I can confirm this. Ouch. Probably need to bump this to major as it is likely to affect any app that uses temporary internet files.
http://bugs.winehq.org/show_bug.cgi?id=23876
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #5 from Dan Kegel dank@kegel.com 2010-09-04 09:20:28 CDT --- Time for a conformance test? Maybe one could be written that sets the limit low, and makes sure it is obeyed.
http://bugs.winehq.org/show_bug.cgi?id=23876
--- Comment #6 from Jerome Leclanche adys.wh@gmail.com 2010-09-12 09:08:42 CDT ---
err:wininet:CommitUrlCacheEntryInternal no free entries fixme:process:GetLogicalProcessorInformation (0x19ee3b4,0x19ee9b4): stub fixme:wininet:InternetSetOptionW Option INTERNET_OPTION_CONNECT_TIMEOUT (60000): STUB fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT 60000 fixme:wininet:URLCache_FindFirstFreeEntry Grow file
I suppose that's the culprit?
http://bugs.winehq.org/show_bug.cgi?id=23876
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |wininet
--- Comment #7 from Juan Lang juan_lang@yahoo.com 2010-09-13 10:32:18 CDT --- (In reply to comment #6)
fixme:wininet:URLCache_FindFirstFreeEntry Grow file
I suppose that's the culprit?
That function probably isn't, but it's probably a wininet bug. Setting component.
http://bugs.winehq.org/show_bug.cgi?id=23876
elhana@sigil-guild.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #8 from elhana@sigil-guild.org 2010-10-24 06:09:07 CDT --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=23876
Vidar Haarr vhaarr+wine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vhaarr+wine@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=23876
Fab netfab+bugs-winehq@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |netfab+bugs-winehq@gmail.co | |m
http://bugs.winehq.org/show_bug.cgi?id=23876
Jérôme Poulin jeromepoulin@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeromepoulin@gmail.com
--- Comment #9 from Jérôme Poulin jeromepoulin@gmail.com 2010-11-23 15:38:35 CST --- I can confirm the same, the Blizzard Downloader from Starcraft II is currently consuming as much in the Temporary Internet Files directory than its destination directory which was more than 7GB after the download.
http://bugs.winehq.org/show_bug.cgi?id=23876
Martin Roth captain_rage@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |captain_rage@hotmail.com
--- Comment #10 from Martin Roth captain_rage@hotmail.com 2010-12-05 12:04:36 CST --- It can be confirmed here also. Running Ubuntu 10.04 LTS, I installed Wine 1.2.0 from the official repositories and Diablo 2 together with it. Technically the game was running fine (2-3 months usage time), but today I was surprised to notice that the folder 'Content.IE5' contained about ~6,500 junk files á 256Kb each, totalling in at 1,7Gb. Maybe it is indeed the update utility that creates those nonsense files.
http://bugs.winehq.org/show_bug.cgi?id=23876
Josue josueorsway@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |josueorsway@gmail.com
--- Comment #11 from Josue josueorsway@gmail.com 2010-12-29 12:40:11 CST --- Same here, I've been playing WoW Cataclysm for half a month and the temporary Internet cache is at about 5.1 Gb.
http://bugs.winehq.org/show_bug.cgi?id=23876
--- Comment #12 from Jerome Leclanche adys.wh@gmail.com 2011-01-19 19:41:58 CST --- Just cleared 44 GiB of data. This needs fixing asap.
http://bugs.winehq.org/show_bug.cgi?id=23876
onlynone@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |onlynone@gmail.com
--- Comment #13 from onlynone@gmail.com 2011-02-22 12:56:03 CST --- I reported an issue like this to codeweavers since I'm running crossover linux:
http://www.codeweavers.com/support/tickets/browse/?ticket_id=837215
What follows is the content of my report:
Anyway, there were 4 or 5 directories underneath the Content.IE5 directory each of which contained hundreds of files totaling 12GB. Even stranger is that they were all named like:
gdroot[0] gdroot[1] gdroot[2] ... gds2-0[0] gds2-0[1] gds2-0[2] ...
Each of the gdroot files were identical at 429 bytes. Running strings on them yields:
============ gdroot START =========== The Go Daddy Group, Inc.110/ (Go Daddy Class 2 Certification Authority 100506191622Z 110506191622Z0 o)dL xkr@N LSyI O+1S ============= gdroot END ============
And each of the gds2-0 files were identical at 266,318 bytes. Running strings on them yields:
============ gds2-0 START =========== Arizona1 Scottsdale1 GoDaddy.com, Inc.1301 *http://certificates.godaddy.com/repository100. 'Go Daddy Secure Certification Authority1 07969287 110222112306Z 110223115306Z0 090401155938Z0 081006090338Z0 [SNIP 7065 LINES] 101216145001Z0 101216145002Z0 101218151502Z0 e0c1 US1!0 The Go Daddy Group, Inc.110/ (Go Daddy Class 2 Certification Authority |<o!3D 5*M;1 {b[| ============= gds2-0 END ============
I deleted all of the files, but they're just coming back again and I'm already up to 66MB after a couple hours. I cannot for the life of me figure out which process is creating the files. I can tell from the output of lsof that the following processes have the Content.IE5 directory or Content.IE5/index.dat file open:
winewrapper.exe (that's running the "Outlook 2007.lnk" file) /opt/cxoffice/bin/wineserver C:\Program Files\Microsoft Office\Office12\OUTLOOK.EXE
http://bugs.winehq.org/show_bug.cgi?id=23876
--- Comment #14 from Juan Lang juan_lang@yahoo.com 2011-02-22 13:42:06 CST --- Created an attachment (id=33405) --> (http://bugs.winehq.org/attachment.cgi?id=33405) Hack: don't cache retrieved files
Does this hack work? (It removes caching of downloaded certificates and CRLs, but it isn't a "real" fix.)
http://bugs.winehq.org/show_bug.cgi?id=23876
--- Comment #15 from Jerome Leclanche adys.wh@gmail.com 2011-02-22 13:42:55 CST --- (In reply to comment #14)
Created an attachment (id=33405)
--> (http://bugs.winehq.org/attachment.cgi?id=33405) [details]
Hack: don't cache retrieved files
Does this hack work? (It removes caching of downloaded certificates and CRLs, but it isn't a "real" fix.)
Applied it. Will report results in a couple of days after a fair bit of playtime.
http://bugs.winehq.org/show_bug.cgi?id=23876
--- Comment #16 from onlynone@gmail.com 2011-02-22 14:33:09 CST --- (In reply to comment #14)
Created an attachment (id=33405)
--> (http://bugs.winehq.org/attachment.cgi?id=33405) [details]
Hack: don't cache retrieved files
Does this hack work? (It removes caching of downloaded certificates and CRLs, but it isn't a "real" fix.)
I don't have a problem with it caching retrieved files, I just don't know why it continues to re-download the same certificate over and over, and doesn't actually re-use the first cached file. That's kind of the whole point of caching.
http://bugs.winehq.org/show_bug.cgi?id=23876
--- Comment #17 from Juan Lang juan_lang@yahoo.com 2011-02-22 14:53:31 CST --- (In reply to comment #16)
I don't have a problem with it caching retrieved files, I just don't know why it continues to re-download the same certificate over and over, and doesn't actually re-use the first cached file. That's kind of the whole point of caching.
That's why it's a hack. I'm trying to determine where the problem lies.
http://bugs.winehq.org/show_bug.cgi?id=23876
--- Comment #18 from onlynone@gmail.com 2011-02-22 15:38:32 CST --- (In reply to comment #17)
(In reply to comment #16)
I don't have a problem with it caching retrieved files, I just don't know why it continues to re-download the same certificate over and over, and doesn't actually re-use the first cached file. That's kind of the whole point of caching.
That's why it's a hack. I'm trying to determine where the problem lies.
Okay, after strace-ing several wine processes for several minutes I found that wineserver is the one creating the certificate files over and over. I can do further tracing if it helps.
http://bugs.winehq.org/show_bug.cgi?id=23876
--- Comment #19 from Dmitry Timoshkov dmitry@codeweavers.com 2011-02-22 21:38:03 CST --- (In reply to comment #18)
Okay, after strace-ing several wine processes for several minutes I found that wineserver is the one creating the certificate files over and over. I can do further tracing if it helps.
strace is not a proper way to debug Wine.
http://bugs.winehq.org/show_bug.cgi?id=23876
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #33405|0 |1 is obsolete| |
--- Comment #20 from Juan Lang juan_lang@yahoo.com 2011-02-23 13:09:53 CST --- (From update of attachment 33405) Commit 2a53eb708796bdf07792c8c34ccb643c11fbfb86 has a better fix for this.
http://bugs.winehq.org/show_bug.cgi?id=23876
--- Comment #21 from Juan Lang juan_lang@yahoo.com 2011-02-23 13:11:22 CST --- Today's git (with commit 2a53eb708796bdf07792c8c34ccb643c11fbfb86) has a fix for the endlessly downloaded CRLs that were flooding the cache in some cases. At least, I hope so ;) The original problem remains: the disk cache isn't bounded, or even possible to clean except manually.
http://bugs.winehq.org/show_bug.cgi?id=23876
--- Comment #22 from onlynone@gmail.com 2011-02-24 15:04:10 CST --- (In reply to comment #21)
Today's git (with commit 2a53eb708796bdf07792c8c34ccb643c11fbfb86) has a fix for the endlessly downloaded CRLs that were flooding the cache in some cases. At least, I hope so ;) The original problem remains: the disk cache isn't bounded, or even possible to clean except manually.
I downloaded the source for crossover from:
http://www.codeweavers.com/products/source/
Applied the above patch to that source tree. Compiled everything. Stopped Outlook and any wine processes. Copied over cryptnet.dll.so to /opt/cxoffice/lib/wine/cryptnet.dll.so. After running Outlook for a few hours, the only files underneath the Content.IE5 directory are:
./W323OMKI/gds2-0[0] ./OOADHISB/gdroot[0]
Both files were created over 3 hours ago. But this patch only affects certificates, right? Wouldn't other code that uses the "Temporary Internet Files" directory have to be changed as well? Is there a common place this change could be made?
http://bugs.winehq.org/show_bug.cgi?id=23876
--- Comment #23 from Juan Lang juan_lang@yahoo.com 2011-02-24 15:24:45 CST --- (In reply to comment #22)
Both files were created over 3 hours ago. But this patch only affects certificates, right? Wouldn't other code that uses the "Temporary Internet Files" directory have to be changed as well? Is there a common place this change could be made?
I already said this didn't fix the underlying issue. There is a common place to fix this, in wininet. I'll stop repeating myself now.
http://bugs.winehq.org/show_bug.cgi?id=23876
--- Comment #24 from Juan Lang juan_lang@yahoo.com 2011-02-25 13:52:16 CST --- I've had a read through wininet, and as far as I can tell, it doesn't make use of its cache at all. It caches all retrieved data unless the cache is disabled, but it never deletes stale data because it never checks whether things it's about to retrieve are cached.
Sigh. This does seem pretty serious. I said I wouldn't repeat myself, but now I will, to collect the issues in one place:
1. wininet doesn't appear to check its cache. This is, at best, a performance drain. 2. wininet doesn't delete stale cache entries. This is a side effect of #1, and it results in the cache filling with repeatedly downloaded data. 3. wininet doesn't bound the size of its cache. A bound combined with a LRU eviction policy could at least mitigate #2. 4. wininet doesn't implement FreeUrlCacheSpace. Providing a function to clear the cache could also help mitigate the problem.
(Note that I am a volunteer, and by commenting on this bug I accept no responsibility for fixing it.)
http://bugs.winehq.org/show_bug.cgi?id=23876
--- Comment #25 from Alexander Scott-Johns alexander.scott.johns+winebug@googlemail.com 2011-02-26 20:51:55 CST --- Created an attachment (id=33464) --> (http://bugs.winehq.org/attachment.cgi?id=33464) Patch to Wine's internet control panel to allow you to manually empty the cache
After this patch is applied, a button to empty the cache is added to the General tab of inetcpl. Run "wine control inetcpl.cpl" to access it.
http://bugs.winehq.org/show_bug.cgi?id=23876
--- Comment #26 from Juan Lang juan_lang@yahoo.com 2011-02-28 11:05:11 CST --- (In reply to comment #25)
Created an attachment (id=33464)
--> (http://bugs.winehq.org/attachment.cgi?id=33464) [details]
Patch to Wine's internet control panel to allow you to manually empty the cache
Thanks Alexander. That's a nice addition. Here's a suggestion: + /* Recursively delete Content.IE5 folder. It will be recreated when + * wininet.dll is next loaded. TODO: Is there a better way? And it + * would be nice to regenerate it right after deleting it. */
The better way is to move the deletion of the files into wininet.dll. According to the Interwebs, native inetcpl.cpl calls FreeUrlCacheSpace with parameters 100, 0 to free the cache.
http://bugs.winehq.org/show_bug.cgi?id=23876
Alexander Scott-Johns alexander.scott.johns+winebug@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #33464|0 |1 is obsolete| |
--- Comment #27 from Alexander Scott-Johns alexander.scott.johns+winebug@googlemail.com 2011-02-28 20:14:42 CST --- Created an attachment (id=33487) --> (http://bugs.winehq.org/attachment.cgi?id=33487) Patch to inetcpl and wininet to allow you to delete history, Temp Internet Files and cookies
(In reply to comment #26)
The better way is to move the deletion of the files into wininet.dll. According to the Interwebs, native inetcpl.cpl calls FreeUrlCacheSpace with parameters 100, 0 to free the cache.
I've partially implemented this, but to do it properly will require implementing {FindFirst,FindNext,Delete}UrlCacheEntry(), which involves iterators, etc. Yuck. (And they are available only on IE5? Does that mean they are not available in IE6+ ?)
And (for future reference) here is a link to some old MS documentation, which includes info about FreeUrlCacheSpace: http://web.archive.org/web/20040604163615/activex.adsp.or.jp/japanese/specs/...
http://bugs.winehq.org/show_bug.cgi?id=23876
Alexander Scott-Johns alexander.scott.johns+winebug@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alexander.scott.johns+wineb | |ug@googlemail.com
--- Comment #28 from Alexander Scott-Johns alexander.scott.johns+winebug@googlemail.com 2011-02-28 20:16:23 CST --- cc-ing myself... why doesn't Bugzilla automatically add users to the cc list when they add an attachment?
http://bugs.winehq.org/show_bug.cgi?id=23876
--- Comment #29 from Juan Lang juan_lang@yahoo.com 2011-02-28 20:28:09 CST --- (In reply to comment #28)
cc-ing myself... why doesn't Bugzilla automatically add users to the cc list when they add an attachment?
You can change your preferences so it will.
http://bugs.winehq.org/show_bug.cgi?id=23876
--- Comment #30 from Juan Lang juan_lang@yahoo.com 2011-03-01 10:20:45 CST ---
I've partially implemented this, but to do it properly will require implementing {FindFirst,FindNext,Delete}UrlCacheEntry(), which involves iterators, etc. Yuck. (And they are available only on IE5? Does that mean they are not available in IE6+ ?)
Doing it "properly" doesn't seem worth the effort. Your approach looks fine. Could you send it as two patches, one for wininet and the other for inetcpl.cpl?
http://bugs.winehq.org/show_bug.cgi?id=23876
--- Comment #31 from Juan Lang juan_lang@yahoo.com 2011-03-01 13:33:57 CST --- (In reply to comment #24)
- wininet doesn't appear to check its cache.
I sent a test case that tries to demonstrate this problem: http://www.winehq.org/pipermail/wine-patches/2011-March/099433.html
http://bugs.winehq.org/show_bug.cgi?id=23876
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #33487|0 |1 is obsolete| |
--- Comment #32 from Juan Lang juan_lang@yahoo.com 2011-03-15 20:20:51 CDT --- (From update of attachment 33487) This was committed as fa19e1bdb30087a3e7dbcc2690890c6b6fc74116 and f9ef35ea6ae9e24085876c6f2d3c77f80266ef3f.
http://bugs.winehq.org/show_bug.cgi?id=23876
Piotr Caban piotr.caban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |piotr.caban@gmail.com
--- Comment #33 from Piotr Caban piotr.caban@gmail.com 2012-09-24 10:31:09 CDT --- This bug should be fixed. Please retest.
Please note that older wine was corrupting cache index file. Please remove Internet cache directory before retesting.
http://bugs.winehq.org/show_bug.cgi?id=23876
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #34 from Jerome Leclanche adys.wh@gmail.com 2012-09-24 13:37:48 CDT --- Looks fixed indeed, Content.IE5 is 36 megs after having played wow for a while.
http://bugs.winehq.org/show_bug.cgi?id=23876
--- Comment #35 from Jerome Leclanche adys.wh@gmail.com 2012-09-24 13:37:55 CDT --- What commit fixed it?
http://bugs.winehq.org/show_bug.cgi?id=23876
Piotr Caban piotr.caban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |66931e4d9fefa959d109807f71f | |ec4967a0c4828
--- Comment #36 from Piotr Caban piotr.caban@gmail.com 2012-09-24 15:05:01 CDT --- Filled fixed by SHA1 field.
http://bugs.winehq.org/show_bug.cgi?id=23876
Martin Roth captain_rage@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|captain_rage@hotmail.com |
http://bugs.winehq.org/show_bug.cgi?id=23876
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #37 from Alexandre Julliard julliard@winehq.org 2012-09-28 13:43:30 CDT --- Closing bugs fixed in 1.5.14.