From ESR 17 this clever stuff cannot be used as the setting has vanished :( Firefox on SL6

Moving Firefox Cache to /tmp/

At various points over the years we have tried a number of things to limit the size of the mozilla and later Firefox Cache directories, none of which worked particularly well.

e.g in earlier versions settings such as browser.cache.disk.capacity worked but later didn't seem to have much effect.

In any case having the Cache in $HOME is slow and adds to the user's quota which can lead to problems. Note that we already avoid backing up those Cache directories.

Previous hacks

So for the past few years on the DAMTP sl machines we have arranged for a script to be run each time firefox is stated which replaces the Cache entry in all the profile directories with symlinks to per-profile directories we make in /tmp/ - so that can't work on first run since the profile directory doesn't yet exist...

Now I just tested and firefox 10.0.3 ESR seems to sometimes ignore or replace the symlink we added - I can't tell exactly when this happens - but it certainly does.

Doing some googling I found various hacks involving setting both XRE_PROFILE_PATH and XRE_PROFILE_LOCAL_PATH the former needing to be set to the normal profile location... This means working out the profile path which can't work for a new profile (as before) and means that we need to read the command-line arguments and parse the profiles.ini to work it out...

Now we already have code in our ffoxhacks.pl to do the parsing, so we could do that - but it would be ugly...

Aside: We can't just set the cache to be the same for all profiles or info will leak between profiles which would be very nasty!

A new hope

However I just found a method which workes better, and can probably replace our current hacks (I hope).

In the firefox .cfg file we can set a defaultPref for the config preference browser.cache.disk.parent_directory which takes effect. The only hard part is working out a profile-specific path.

This is the code I just added to our damtpfirefox100.cfg.txt file which will be pushed to all our machines overnight:

var env_user = getenv("USER");
var env_home    = getenv("HOME");
var env_mozdebug= getenv("MOZILLA_DEBUG");
// find the path to the profile directory
var profhome = Components.classes["@mozilla.org/file/directory_service;1"].getService(Components.interfaces.nsIProperties).get("ProfD",
                 Components.interfaces.nsIFile).path;
// work out the profile salt+name
var profname=profhome.match(/[^\/]+$/);

// this matches what our hack wrapper symlinked the Cache into...
var cache_dir = "/tmp/MozillaFirefox-" + env_user + "/" + profname;
defaultPref('browser.cache.disk.parent_directory', cache_dir);

I also added the following for debugging (if MOZILLA_DEBUG is set it pops up a window with text in it):

if (env_mozdebug) {
    displayError("debug ffox cfg v100",
                 "\n\nuser=" + env_user +
                 "\nhome=" + env_home +
                 "\n\nprofile-path="+profhome +
                 "\nprofile-name="+profname
                 );
}

and wrapped the whole thing in a try/catch pair for when I got the syntax wrong.

So a user foo12 running with a profile ~/.mozilla/firefox/vo1a5372.default would have browser.cache.disk.parent_directory set to:

  /tmp/MozillaFirefox-foo12/vo1a5372.default/Cache

and firefox even takes care of creating that with sane permissions if it doesn't already exist.

The only scary part of that is the magic Components.classes... which I happened to find described in a mozilla kb article so it is probably safe for now....

Now this looks easy enough, but I spent ages battling adding it into the .js file we load from the web server - in there a defaultPref setting appears ok in about:config but is completely ignored by the browser. I'm guessing that file is read after the Cache has already been set up...

Now this ought to apply to the dpmms or statslab linux machines too, though I've not tested on anything before firefox 10.0.3 ESR.

I'd guess that a similar piece of code added into the .cfg might be usable on Windows or MacOSX though the result of the profhome lookup will be different so the .match might need to be tweaked too. Still it might allow moving the Cache out of the home (or profile) trees and maybe make things a big faster for users.