On Wed, 16 Jul 2008, Jon Peatfield wrote:

<snip>
> Anyway according to the entry at:
>
>  http://kb.mozillazine.org/Browser.cache.disk.parent_directory
>
> the value of browser.cache.disk.parent_directory defaults to some 'temp' 
> storage on firefox >= 1.5.
>
> Looking at about:config on an sl51 box running ffox1.5 (yes I know this is 
> getting rather old), I see that for me it is currently set to:
>
>  /tmp/MozillaFirefox-jp107/Cache/
>
> without me needing to fix anything.  Woo hoo one fewer thing to have to worry 
> about setting in any central config stuff!

Well I spoke too soon.  It seems that browser.cache.disk.parent_directory 
was being set to /tmp/... by our existing autoconfig stuff (so long ago 
that I'd forgotten we were doing that).  However it was being ignored and 
the cache still ends up in the profile directory...

For me firefox 1.5 and 3.0.1 setting browser.cache.disk.parent_directory 
seems to have no effect in where the cache ends up.  I've checked to see 
if having the directory already existing makes any difference (it 
doesn't), and made the permissions mode 700 just in case it was feeling 
paranoid.  This may explain why we currently set the disk cache size 
default to 0.

So does setting browser.cache.disk.parent_directory work for anyone else?

So far the only thing I've found that works is:

   ensure that the /tmp/... directory exists

   remove the profile Cache directory and symlink that to it

Obviously that means doing a walk through profiles.ini but isn't going to 
be a big problem (we already have to put a wrapper round firefox anyway).

So if we do the symlink of Cache to /tmp/... thing then should we:

   make one for all profiles or

   one for each profile

I suppose that one per profile is safest since otherwise info may leak 
between them, though it might use more space in /tmp.

So far testing with ffox 3.0.1 I've found the following things we need to 
do differently:

Create the 'missing' symlinks from the /usr/{libdir}/firefox-{version}/

   'plugins' => '/usr/lib/xulrunner-1.9/plugins'
   'defaults/autoconfig' => '/usr/lib/xulrunner-1.9/defaults/autoconfig'

drop our all-damtp.js overrides into defaults/preferences/all-damtp.js 
(was in greprefs/ and defaults/pref/).

On firefox-1.5 we used to set:

pref("browser.startup.homepage", "resource:/browserconfig.properties");
pref("browser.startup.homepage_reset", "resource:/browserconfig.properties");

and then have the real locations specified in the browserconfig.properties 
file.  In 3.0.1 if we set those then on startup it displays 
resource:///browserconfig.properties and shows those contents.  However it 
seems that now we can just set:

pref("browser.startup.homepage", "$DEFURL");
pref("browser.startup.homepage_reset", "$DEFURL");
pref("startup.homepage_override_url", "$DEFURL");
pref("startup.homepage_welcome_url", "$DEFURL");

(where DEFURL is set in that script) to set the defaults without 
preventing people from changing the defaults.  I can't remember why we 
started using the resource:/browserconfig.properties stuff, but there was 
probably a fairly good reason.

Troy/Connie you may not have spotted the following in 
defaults/preferences/all-redhat.js but you may want to correct the 
bits that mention redhat.

...
pref("general.useragent.vendor", "Red Hat");
...
pref("browser.startup.homepage", "file:///usr/share/doc/HTML/index.html");
pref("startup.homepage_override_url", "http://www.redhat.com/firefox-welcome/");
pref("startup.homepage_welcome_url", "http://www.redhat.com/firefox-welcome/");

Now I just need to worry about all those sqlite files and the impact that 
may have over NFS and backups...

  -- Jon