IE/Wininet cache breaks when it has lots of small files in it, is there any work around?

[William Bardwell]

If you have your IE/Wininet cache set fairly large (600M or so), and you
access lots of tiny files, when the cache gets around 30000 files in it
but has not used up all of the disk space quota (nor filled in the
disk), it stops taking new files, and just fails to cache anything.

This bug seems to be fairly old, but still present in current versions
of IE/wininet. Anyone know when they might fix this? Is there any work
around inside of a program aside from just using
FindFirstUrlCacheGroup/FindNextUrlCacheGroup/DeleteUrlCacheGroup when
you suspect that it is broken, or just setting the cache to something
small (I have seen the bug with as little as 380M, but it seems to vary
with the machine, and maybe the exact URLs being used), or telling your
users that MSC has a bug, and that they should clear the cache manually?

Thanks.
William Bardwell

[Paul Baker]

I wonder if there is a limit of 32,767 files?

Paul

Post by William Bardwell
If you have your IE/Wininet cache set fairly large (600M or so), and you
access lots of tiny files, when the cache gets around 30000 files in it
but has not used up all of the disk space quota (nor filled in the disk),
it stops taking new files, and just fails to cache anything.
This bug seems to be fairly old, but still present in current versions of
IE/wininet. Anyone know when they might fix this? Is there any work
around inside of a program aside from just using
FindFirstUrlCacheGroup/FindNextUrlCacheGroup/DeleteUrlCacheGroup when you
suspect that it is broken, or just setting the cache to something small (I
have seen the bug with as little as 380M, but it seems to vary with the
machine, and maybe the exact URLs being used), or telling your users that
MSC has a bug, and that they should clear the cache manually?
Thanks.
William Bardwell

[Stephen Sulzer]

The WinInet cache does have a limit on the maximum number of items in the
cache, regardless of the disk space quota. Each item in the WinInet cache is
recorded in the index.dat file, which is the database that WinInet uses to
manage the cache. The index.dat file imposes the cache item limit. The limit
is not documented, and it varies a bit based on what kind of items are in
the cache.

One indication that the cache is full is that CommitUrlCacheEntry returns
ERROR_NOT_ENOUGH_MEMORY.

WinInet does implement a mechanism to delete old entries from the cache to
make space for new items. However, I think this clean up is triggered by
exceeding the disk quota, not by filling up the index.dat table, so that
could be considered a bug.

In any case, the WinInet cache implementation needs a big over-haul.

- Stephen

[Paul Baker]

I don't think there's going to be over-haul.

Caching is adequate
WinHTTP is already available.
People who find the FTP implementation restrictive can use and are using
third party software.

Paul

Post by Stephen Sulzer
The WinInet cache does have a limit on the maximum number of items in the
cache, regardless of the disk space quota. Each item in the WinInet cache is
recorded in the index.dat file, which is the database that WinInet uses to
manage the cache. The index.dat file imposes the cache item limit. The limit
is not documented, and it varies a bit based on what kind of items are in
the cache.
One indication that the cache is full is that CommitUrlCacheEntry returns
ERROR_NOT_ENOUGH_MEMORY.
WinInet does implement a mechanism to delete old entries from the cache to
make space for new items. However, I think this clean up is triggered by
exceeding the disk quota, not by filling up the index.dat table, so that
could be considered a bug.
In any case, the WinInet cache implementation needs a big over-haul.
- Stephen

[Louis Solomon [SteelBytes]]

this not applicable when the cache functions are being used in an async
pluggable protocol that feeds data to a iwebbrowser2
--
Louis Solomon
www.SteelBytes.com

Post by Paul Baker
I don't think there's going to be over-haul.
Caching is adequate
WinHTTP is already available.
People who find the FTP implementation restrictive can use and are using
third party software.
Paul

Post by Stephen Sulzer
The WinInet cache does have a limit on the maximum number of items in the
cache, regardless of the disk space quota. Each item in the WinInet cache is
recorded in the index.dat file, which is the database that WinInet uses to
manage the cache. The index.dat file imposes the cache item limit. The limit
is not documented, and it varies a bit based on what kind of items are in
the cache.
One indication that the cache is full is that CommitUrlCacheEntry returns
ERROR_NOT_ENOUGH_MEMORY.
WinInet does implement a mechanism to delete old entries from the cache to
make space for new items. However, I think this clean up is triggered by
exceeding the disk quota, not by filling up the index.dat table, so that
could be considered a bug.
In any case, the WinInet cache implementation needs a big over-haul.
- Stephen

[William Bardwell]

MSC says that this bug is fixed in a recent security pack:
MS04-038 at http://www.microsoft.com/technet/security/bulletin/ms04-038.mspx

But apparently that doesn't fix it on XP SP2, a fix for that should be
out "by the end of May"

William

[Louis Solomon [SteelBytes]]

yes, I've found this problem myself. atlhough it was around 60000 files for
me. I endded up just doing a findfirst/delete on the cache items. I am
also trying to get an answer out of MSFT, but they don't seem to understand
that there is a problem. search google's histroy of this group for previous
posts by me a couple of months ago on this topic.
--
Louis Solomon
www.SteelBytes.com

Post by William Bardwell
If you have your IE/Wininet cache set fairly large (600M or so), and you
access lots of tiny files, when the cache gets around 30000 files in it
but has not used up all of the disk space quota (nor filled in the disk),
it stops taking new files, and just fails to cache anything.
This bug seems to be fairly old, but still present in current versions of
IE/wininet. Anyone know when they might fix this? Is there any work
around inside of a program aside from just using
FindFirstUrlCacheGroup/FindNextUrlCacheGroup/DeleteUrlCacheGroup when you
suspect that it is broken, or just setting the cache to something small (I
have seen the bug with as little as 380M, but it seems to vary with the
machine, and maybe the exact URLs being used), or telling your users that
MSC has a bug, and that they should clear the cache manually?
Thanks.
William Bardwell

[Paul Baker]

Sometimes it is difficult for us, as programmers, to realise that there is a
problem and the exact nature of the problem without steps to reproduce.

I myself talked to Microsoft for a couple of months on and off before a
problem I was having was truly understood. At that point, it was resolved
within days! Things just fell into place when the understanding was there.
We had difficulty in communicating the steps to reproduce, because although
I could tell them it in terms of API calls, they preferred to use a VB
program and I preferred to write it in Delphi. I resolved this issue by
giving the steps to reproduce using their own program after a couple of
iterations of it made it behave the same as my own. And there were factors
involved that none of us thought were relevant to the problem until later.

Anyway, my point is, do you have a sample program that reproduces a problem
starting with an empty cache on Windows XP and a version of WinInet that it
corresponds to?

Paul

Post by Louis Solomon [SteelBytes]
yes, I've found this problem myself. atlhough it was around 60000 files
for me. I endded up just doing a findfirst/delete on the cache items. I
am also trying to get an answer out of MSFT, but they don't seem to
understand that there is a problem. search google's histroy of this group
for previous posts by me a couple of months ago on this topic.
--
Louis Solomon
www.SteelBytes.com

Post by William Bardwell
If you have your IE/Wininet cache set fairly large (600M or so), and you
access lots of tiny files, when the cache gets around 30000 files in it
but has not used up all of the disk space quota (nor filled in the disk),
it stops taking new files, and just fails to cache anything.
This bug seems to be fairly old, but still present in current versions of
IE/wininet. Anyone know when they might fix this? Is there any work
around inside of a program aside from just using
FindFirstUrlCacheGroup/FindNextUrlCacheGroup/DeleteUrlCacheGroup when you
suspect that it is broken, or just setting the cache to something small
(I have seen the bug with as little as 380M, but it seems to vary with
the machine, and maybe the exact URLs being used), or telling your users
that MSC has a bug, and that they should clear the cache manually?
Thanks.
William Bardwell

[William Bardwell]

Post by Paul Baker
Sometimes it is difficult for us, as programmers, to realise that there is a
problem and the exact nature of the problem without steps to reproduce.

[...programming support is hard...]

Post by Paul Baker
Anyway, my point is, do you have a sample program that reproduces a problem
starting with an empty cache on Windows XP and a version of WinInet that it
corresponds to?

All that you need to do is load a whole bunch of small files, my sample
is in the langauge that I am working on, but doing
UrlDownloadToCacheFile will hit the same thing. To let me load an
inifinite number of small files, I just made a CGI script on my web
server, so that I can just load <cgi-url>/<timestamp>.<counter>/test.txt

There is no rocket science involved here. I guess I get to do the joy
of a MSC incident.

Someone there does know about the problem, but the company hasn't put up
any support information about it or when it might be fixed, or if there
are any work arounds. See:
http://blogs.msdn.com/jeffdav/archive/2004/10/29/249742.aspx

Post by Paul Baker
Paul

Post by Louis Solomon [SteelBytes]
yes, I've found this problem myself. atlhough it was around 60000 files
for me. I endded up just doing a findfirst/delete on the cache items. I
am also trying to get an answer out of MSFT, but they don't seem to
understand that there is a problem. search google's histroy of this group
for previous posts by me a couple of months ago on this topic.
--
Louis Solomon
www.SteelBytes.com

Post by William Bardwell
If you have your IE/Wininet cache set fairly large (600M or so), and you
access lots of tiny files, when the cache gets around 30000 files in it
but has not used up all of the disk space quota (nor filled in the disk),
it stops taking new files, and just fails to cache anything.
This bug seems to be fairly old, but still present in current versions of
IE/wininet. Anyone know when they might fix this? Is there any work
around inside of a program aside from just using
FindFirstUrlCacheGroup/FindNextUrlCacheGroup/DeleteUrlCacheGroup when you
suspect that it is broken, or just setting the cache to something small
(I have seen the bug with as little as 380M, but it seems to vary with
the machine, and maybe the exact URLs being used), or telling your users
that MSC has a bug, and that they should clear the cache manually?
Thanks.
William Bardwell

[Stephen Sulzer]

Probably the only workaround is to set the cache disk quota small enough
(say, 20 to 30 MB) so that you hit the cache size limit before the index.dat
table entry limit (at which point WinInet is stuck). When the disk quota is
exceeded, WinInet starts the scavenger thread to delete old entries.

Maybe, hopefully, this problem will be fixed for IE7.

- Stephen

[Paul Baker]

William,

You're still kind of missing my point that there is no substitue for steps
to reproduce.

If it is as simple as this and Microsoft has not acknowledged it, what does
that tell you?

Paul

Post by William Bardwell

Post by Paul Baker
Sometimes it is difficult for us, as programmers, to realise that there
is a problem and the exact nature of the problem without steps to
reproduce.

[...programming support is hard...]

Post by Paul Baker
Anyway, my point is, do you have a sample program that reproduces a
problem starting with an empty cache on Windows XP and a version of
WinInet that it corresponds to?

All that you need to do is load a whole bunch of small files, my sample is
in the langauge that I am working on, but doing UrlDownloadToCacheFile
will hit the same thing. To let me load an inifinite number of small
files, I just made a CGI script on my web server, so that I can just load
<cgi-url>/<timestamp>.<counter>/test.txt
There is no rocket science involved here. I guess I get to do the joy of
a MSC incident.
Someone there does know about the problem, but the company hasn't put up
any support information about it or when it might be fixed, or if there
http://blogs.msdn.com/jeffdav/archive/2004/10/29/249742.aspx

Post by Paul Baker
Paul

Post by Louis Solomon [SteelBytes]
yes, I've found this problem myself. atlhough it was around 60000 files
for me. I endded up just doing a findfirst/delete on the cache items. I
am also trying to get an answer out of MSFT, but they don't seem to
understand that there is a problem. search google's histroy of this group
for previous posts by me a couple of months ago on this topic.
--
Louis Solomon
www.SteelBytes.com

Post by William Bardwell
If you have your IE/Wininet cache set fairly large (600M or so), and you
access lots of tiny files, when the cache gets around 30000 files in it
but has not used up all of the disk space quota (nor filled in the
disk), it stops taking new files, and just fails to cache anything.
This bug seems to be fairly old, but still present in current versions
of IE/wininet. Anyone know when they might fix this? Is there any work
around inside of a program aside from just using
FindFirstUrlCacheGroup/FindNextUrlCacheGroup/DeleteUrlCacheGroup when
you suspect that it is broken, or just setting the cache to something
small (I have seen the bug with as little as 380M, but it seems to vary
with the machine, and maybe the exact URLs being used), or telling your
users that MSC has a bug, and that they should clear the cache manually?
Thanks.
William Bardwell

[Louis Solomon [SteelBytes]]

in a word: yes.

I wrote a small test prog that just creates lots of cache files and commits
them.
I run this on a xp sp2 box after clearing the ie cache, and it gives me
ERROR_DISK_FULL when the disk is not full, and the cache is not full
(according to count of used MB). it seems to be number of items based.

see attchemtn for code
--
Louis Solomon
www.SteelBytes.com

Post by Paul Baker
Sometimes it is difficult for us, as programmers, to realise that there is a
problem and the exact nature of the problem without steps to reproduce.
I myself talked to Microsoft for a couple of months on and off before a
problem I was having was truly understood. At that point, it was resolved
within days! Things just fell into place when the understanding was there.
We had difficulty in communicating the steps to reproduce, because although
I could tell them it in terms of API calls, they preferred to use a VB
program and I preferred to write it in Delphi. I resolved this issue by
giving the steps to reproduce using their own program after a couple of
iterations of it made it behave the same as my own. And there were factors
involved that none of us thought were relevant to the problem until later.
Anyway, my point is, do you have a sample program that reproduces a problem
starting with an empty cache on Windows XP and a version of WinInet that it
corresponds to?
Paul

Post by Louis Solomon [SteelBytes]
yes, I've found this problem myself. atlhough it was around 60000 files
for me. I endded up just doing a findfirst/delete on the cache items. I
am also trying to get an answer out of MSFT, but they don't seem to
understand that there is a problem. search google's histroy of this group
for previous posts by me a couple of months ago on this topic.
--
Louis Solomon
www.SteelBytes.com

Post by William Bardwell
If you have your IE/Wininet cache set fairly large (600M or so), and you
access lots of tiny files, when the cache gets around 30000 files in it
but has not used up all of the disk space quota (nor filled in the disk),
it stops taking new files, and just fails to cache anything.
This bug seems to be fairly old, but still present in current versions of
IE/wininet. Anyone know when they might fix this? Is there any work
around inside of a program aside from just using
FindFirstUrlCacheGroup/FindNextUrlCacheGroup/DeleteUrlCacheGroup when you
suspect that it is broken, or just setting the cache to something small
(I have seen the bug with as little as 380M, but it seems to vary with
the machine, and maybe the exact URLs being used), or telling your users
that MSC has a bug, and that they should clear the cache manually?
Thanks.
William Bardwell

begin 666 main.cpp
M(VEN8VQU9&4@(G-T9&%F>"YH(@T*(W!R86=M82!H9')S=&]P#0HC:6YC;'5D
M92 B=6YI8V]D92YH(@T*#0IS=&%T:6,@1%=/***@0T%,3$)!***@37E4:')E
M860H3%!63TE$(&QP4&%R86UE=&5R*0T*>PT*"49)3$5424U%(&UO9'1I;64[
M#0H)1V5T4WES=&5M5&EM94%S1FEL951I;64H)FUO9'1I;64I.PT*"49)3$54
M24U%(&5X<&ER971I;64[#0H)*BA?7VEN=#8T*BDF97AP:7)E=&EM92 ]("@J
M*%]?:6YT-C0J*29M;V1T:6UE*2 K("A?7VEN=#8T*3$P*C$P,# J,3 P,"HS
M-C P*C(T*C$[#0H-"@EF;W(@*&EN="!I/3 [:3PH,3 R-"HQ,#(T*3LK*VDI
M#0H)>PT*"0E70TA!4B!U<FQ;,C4V73L-"@D)4W1R:6YG0V-H4')I;G1F5RAU
M<FPL4U1224Y'7TQ%3D=42"AU<FPI+$PB:'1T<#HO+V9I;&PN8V%C:&4N=&5S
M="\E:2XE:2XE:2XE:2(L<F%N9"@I+')A;F0H*2QR86YD*"DL<F%N9"@I*3L-
M"@D)8V]N<W0@<W1A=&EC(&EN="!L96YG=&@@/2 V-#L-"@D)5T-(05(@8V%C
M:&5?9FEL96YA;65;34%87U!!5$A=.PT*"0EC;VYS="!S=&%T:6,@5T-(05(@
M9FEL95]E>'1;72 ]($PB='-T(CL-"@D)5D522499*%5N:5]#<F5A=&55<FQ#
M86-H945N=')Y*'5R;"QL96YG=&@L9FEL95]E>'0L8V%C:&5?9FEL96YA;64L
M,"DI.PT*"0E(04Y$3$***@9FEL96AA;F1L92 ](%5N:5]#<F5A=&5&:6QE*&-A
M8VAE7V9I;&5N86UE+$=%3D5224-?5U))5$4L,"Q.54Q,+$-214%415]!3%=!
M65,L,"Q.54Q,*3L-"@D)05-315)4*&9I;&5H86YD;&4A/4E.5D%,241?2$%.
M1$Q%7U9!3%5%*3L-"@D):68@*&9I;&5H86YD;&4A/4E.5D%,241?2$%.1$Q%
M7U9!3%5%*0T*"0E[#0HC:68@,0T*"0D)+R]$979I8V5);T-O;G1R;VPH9FEL
M96AA;F1L92Q&4T-43%]3151?4U!!4E-%+# L,"PP+# L,"PP*3L-"@D)"5-E
M=$9I;&50;VEN=&5R*&9I;&5H86YD;&4L;&5N9W1H+$Y53$PL1DE,15]"14=)
M3BD[#0H)"0E3971%;F1/9D9I;&4H9FEL96AA;F1L92D[#0HC96QS90T*"0D)
M1%=/4D0@=&5M<#L-"B-D969I;***@8G5F7W-I>F4@,38S.#0-"@D)"4)95$4@
M*F)U9B ]("A"651%("HI;7EM86QL;V,H8G5F7W-I>F4I.PT*"0D):6YT(&QE
M;F=T:#(@/2!L96YG=&@[#0H)"0EW:&EL92 H;&5N9W1H,CXP*0T*"0D)>PT*
M"0D)"6EN="!L.PT*"0D)"6EF("AL96YG=&@R/F)U9E]S:7IE*0T*"0D)"0EL
M(#***@8G5F7W-I>F4[#0H)"0D)96QS90T*"0D)"0EL(#T@;&5N9W1H,CL-"@D)
M"0EL96YG=&@R("T](&P[#0H)"0D)9F]R("AI;G0@:6D],#MI:3QL.RLK:6DI
M#0H)"0D)"6)U9EMI:5T@/2 H0EE412ER86YD*"D[#0H)"0D)5D522499*%=R
M:71E1FEL92AF:6QE:&%N9&QE+&)U9BQL+"9T96UP+$Y53$PI*3M!4U-%4E0H
M;#T]=&5M<"D[#0H)"0E]#0H)"0EM>69R964H8G5F*3L-"B-E;***@T*"0D)
M0VQO<V5(86YD;&4H9FEL96AA;F1L92D[#0H-"@D)"6EN="!S869T97D@/2 P
M.PT*86=A:6XZ#0H)"0E"3T],(&-O;6UI=%]R97-U;'0@/2!5;FE?0V]M;6ET
M57)L0V%C:&5%;G1R>2AU<FPL8V%C:&5?9FEL96YA;64L97AP:7)E=&EM92QM
M;V1T:6UE+$Y/4DU!3%]#04-(15]%3E1262Q.54Q,+# L9FEL95]E>'0L3E5,
M3"D[#0HC:68@, T*"0D):68@*"@A8V]M;6ET7W)E<W5L="D@)B8@*"AS869T
M97DK*RD\,3 P*2D-"@D)"7L-"@D)"0E44D%#12A,(F-L96%R:6YG('-O;64@
M;V8@=&AE(&-A8VAE7')<;B(I.PT*(V1E9FEN92!B=69?<W5Z92 T,#DV#0H)
M"0D)1%=/4D0@:5-I>F4[#0H)"0D)24Y415).151?0T%#2$5?14Y44EE?24Y&
M3U<@*G-%;G1R>4EN9F\@/2 H24Y415).151?0T%#2$5?14Y44EE?24Y&3U<@
M*BEM>6UA;&QO8RAB=69?<W5Z92D[#0H)"0D):5-I>F4@/2!B=69?<W5Z93L-
M"@D)"0ES16YT<GE);F9O+3YD=U-T<G5C=%-I>F4@/2!S:7IE;V8H24Y415).
M151?0T%#2$5?14Y44EE?24Y&3U<I.PT*"0D)"4A!3D1,12!F:6YD(#***@1FEN
M9$9I<G-T57)L0V%C:&5%;G1R>5<H3E5,3"QS16YT<GE);F9O+"9I4VEZ92D[
M#0H)"0D):68@*&9I;F0I#0H)"0D)>PT*"0D)"0EF;W(@*&EN="!Z/3 [>CPQ
M,# P.RLK>BD-"@D)"0D)>PT*"0D)"0D)1&5L971E57)L0V%C:&5%;G1R>5<H
M<T5N=')Y26YF;RT^;'!S>E-O=7)C955R;$YA;64I.PT*"0D)"0D):5-I>F4@
M/2!B=69?<W5Z93L-"@D)"0D)"7-%;G1R>4EN9F\M/F1W4W1R=6-T4VEZ92 ]
M('-I>F5O9BA)3E1%4DY%5%]#04-(15]%3E1265])3D9/5RD[#0H)"0D)"0EI
M9B H(49I;F1.97AT57)L0V%C:&5%;G1R>5<H9FEN9"QS16YT<GE);F9O+"9I
M4VEZ92DI#0H)"0D)"0D)8G)E86L[#0H)"0D)"7T-"@D)"0D)1FEN9$-L;W-E
M57)L0V%C:&4H9FEN9"D[#0H)"0D)?0T*"0D)"6UY9G)E92AS16YT<GE);F9O
M*3L-"@D)"0EG;W1O(&%G86EN.PT*"0D)?0T*(V5N9&EF#0H)"0EI9B H(6-O
M;6UI=%]R97-U;'0I#0H)"0E[#0H)"0D)1%=/***@9V5T7VQA<W1?97)R;W(@
M/2!'971,87-T17)R;W(H*3L-"@D)"0E70TA!4B!E<G)O<E]T97AT6S$P,C1=
M.PT*"0D)"49O<FUA=$UE<W-A9V57*$9/4DU!5%]-15-304=%7T923TU?4UE3
M5$5-?$9/4DU!5%]-15-304=%7TE'3D]215])3E-%4E13+$Y53$PL9V5T7VQA
M<W1?97)R;W(L34%+14Q!3D=)1"A,04Y'7TY%551204PL4U5"3$%.1U]$149!
M54Q4*2QE<G)O<E]T97AT+%-44DE.1U],14Y'5$@H97)R;W)?=&5X="DL3E5,
M3"D[#0H)"0D)5T-(05(@<W-S6S$P,C1=.PT*"0D)"5-T<FEN9T-C:%!R:6YT
M9E<H<W-S+%-44DE.1U],14Y'5$@H<W-S*2Q,(F9A:6QE9"!5;FE?0V]M;6ET
M57)L0V%C:&5%;G1R>2A<(B5S7"(L7"(E<UPB+"XN+BQ<(B5S7"(I7')<;D=E
M=$QA<W1%<G)O<***@I("T^("4P.'@@.B!<(B5S7"(B+ T*"0D)"0EU<FPL8V%C
M:&5?9FEL96YA;64L9FEL95]E>'0L9V5T7VQA<W1?97)R;W(L97)R;W)?=&5X
M="D[#0H)"0D)5%)!0T4H3"(E<UQR7&XB+'-S<RD[#0H)"0D)05-315)4*# I
M.PT*"0D)?0T*"0E]#0H-"@E]#0H)<F5T=7)N(# [#0I]#0H-"FEN="!M86EN
M*"D-"GL-"@E5;FE?:6YI="@I.PT*"6EN:71M>6UA;&***@I.PT*"7-R86YD
M*$=E=%1I8VM#;W5N="@I*3L-"@T*(V1E9FEN92!N=6U?=&AR96%D<R Q-@T*
M"4A!3D1,12!T:')E861S6VYU;5]T:')E861S73L-"@EF;W(@*&EN="!I/3 [
M:3QN=6U?=&AR96%D<SLK*VDI#0H)>PT*"0E$5T]21"!I9#L-"@D)=&AR96%D
M<UMI72 ]($-R96%T951H<F5A9"A.54Q,+# L37E4:')E860L,"PP+"9I9"D[
M#0H)?0T*"5=A:71&;W)-=6QT:7!L94]B:F5C=',H;G5M7W1H<F5A9',L=&AR
M96%D<RQ44E5%+$E.1DE.251%*3L-"@T*#0H)9&]N96UY;6%L;&]C*"D[#0H)
.<F5T=7)N(# [#0I]#0H`
`
end

[Paul Baker]

Nice example, thanks.

Paul

Post by Louis Solomon [SteelBytes]
in a word: yes.
I wrote a small test prog that just creates lots of cache files and
commits them.
I run this on a xp sp2 box after clearing the ie cache, and it gives me
ERROR_DISK_FULL when the disk is not full, and the cache is not full
(according to count of used MB). it seems to be number of items based.
see attchemtn for code
--
Louis Solomon
www.SteelBytes.com

Post by Paul Baker
Sometimes it is difficult for us, as programmers, to realise that there is a
problem and the exact nature of the problem without steps to reproduce.
I myself talked to Microsoft for a couple of months on and off before a
problem I was having was truly understood. At that point, it was resolved
within days! Things just fell into place when the understanding was there.
We had difficulty in communicating the steps to reproduce, because although
I could tell them it in terms of API calls, they preferred to use a VB
program and I preferred to write it in Delphi. I resolved this issue by
giving the steps to reproduce using their own program after a couple of
iterations of it made it behave the same as my own. And there were factors
involved that none of us thought were relevant to the problem until later.
Anyway, my point is, do you have a sample program that reproduces a problem
starting with an empty cache on Windows XP and a version of WinInet that it
corresponds to?
Paul

Post by Louis Solomon [SteelBytes]
yes, I've found this problem myself. atlhough it was around 60000 files
for me. I endded up just doing a findfirst/delete on the cache items.
I
am also trying to get an answer out of MSFT, but they don't seem to
understand that there is a problem. search google's histroy of this group
for previous posts by me a couple of months ago on this topic.
--
Louis Solomon
www.SteelBytes.com

Post by William Bardwell
If you have your IE/Wininet cache set fairly large (600M or so), and you
access lots of tiny files, when the cache gets around 30000 files in it
but has not used up all of the disk space quota (nor filled in the disk),
it stops taking new files, and just fails to cache anything.
This bug seems to be fairly old, but still present in current versions of
IE/wininet. Anyone know when they might fix this? Is there any work
around inside of a program aside from just using
FindFirstUrlCacheGroup/FindNextUrlCacheGroup/DeleteUrlCacheGroup when you
suspect that it is broken, or just setting the cache to something small
(I have seen the bug with as little as 380M, but it seems to vary with
the machine, and maybe the exact URLs being used), or telling your users
that MSC has a bug, and that they should clear the cache manually?
Thanks.
William Bardwell