[RFC][Icedtea-Web]: Enforce cache size limit.

[Andrew Su]

----- Original Message -----
> From: "Deepak Bhole" <dbhole at redhat.com>
> To: "Andrew Su" <asu at redhat.com>
> Cc: "IcedTea" <distro-pkg-dev at openjdk.java.net>
> Sent: Tuesday, April 19, 2011 10:14:37 AM
> Subject: Re: [RFC][Icedtea-Web]: Enforce cache size limit.
> * Andrew Su <asu at redhat.com> [2011-04-19 09:46]:
> >
> >
> > >
> <snip>
> >
> > When I said root directory, I meant it as in the unique folder to
> > the item.
> > Such as "/home/user1/.icedtea/cache/3"
> >
> 
> Okay. That will nuke everything in the cache from existing (current
> format) cache dirs, but it is okay as that cache will never get used
> anyway.
> 
> > >
> > >
> > > > + long len = file.length();
> > > >
> > > > - if (delete || keep.contains(rStr)) {
> > > > + if (delete || !file.isFile() || (maxSize >= 0 && curSize + len
> > > > >
> > > > maxSize) || keep.contains(rStr)) {
> > >
> > > Can you clarify the logic here (in a comment as well) please?
> > >
> > > 1. if delete == true, delete .... this is OK
> > >
> > > 2. if !file.isFile() .... would getLRUSortedEntries() ever return
> > > a
> > > dir?
> >
> > No, and it shouldn't, but let's say, directory was created but the
> > actual item doesn't exist. If the item wasn't marked for deletion
> > we'll have an empty folder lying around, should get rid of it.
> > (This seems to go with previous patch more, missed this case)
> >
> 
> Fair enough.
> 
> > >
> > > 3. (maxSize >= 0 && curSize + len > maxSize) ... okay, sounds
> > > reasonable, this is current behaviour
> > >
> > > 4. keep.contains(rStr) ... the else part of that block adds rStr
> > > to
> > > keep. Can there be a case where it shows up again during the
> > > iteration?
> >
> > Nope, it doesn't the second add to keep is for use with
> > removeUntrackedDirectories()
> > Cheers,
> 
> Okay.
> 
> One last thing that just came to mind.. if I accidentally specify
> $HOME
> as the cachedir with size < sizeof($HOME), won't this patch nuke all
> of it?

Yup it would, but that fix should be separate from this, as that issue is also affected by calling clearcache from javaws.

+ in response to http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013708.html I have attached an updated version of the patch which correctly checks for the right string. (Even though it won't matter -for now- since both these entries will be in 'keep').

Attched patch has the change specified above.

Cheers,
  Andrew

--snip--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch2.patch
Type: text/x-patch
Size: 3466 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110419/464db1f9/patch2.patch