Whilst the previous Cool Solution only redirected urlclassifer3.sqlite, this method redirected urlclassifer3.sqlite, Cache, OfflineCache and the fastloader files XUL.mfasl XPC.mfasl. This method also uses environment variables rather than creating a symbolic link, so it’s cleaner.
I figured out this solution after reading a bug report at https://bugzilla.mozilla.org/show_bug.cgi?id=239254
The trick is to launch Firefox with both $XRE_PROFILE_PATH set to the location of the profile that’s being used and $XRE_PROFILE_LOCAL_PATH set to where you want Cache, urlclassifer3.sqlite etc to be. Like the previous Cool Solution, a wrapper script called firefox in /usr/local/bin takes care of that. Also like the previous Cool Solution, this wrapper script makes use of another script findfirefoxprofilepath, also attached, which works out the location of the user’s Firefox profile (it’s output is set as the value of $XRE_PROFILE_PATH). The firefox script expects the findfirefoxprofilepath script to be in /usr/local/sbin.
If $XDG_CACHE_HOME is set, the firefox script sets $XRE_PROFILE_LOCAL_PATH to somewhere in there. (It will always use the same location so the files will persist across sessions, assuming they’re not deleted by something else.) If $XDG_CACHE_HOME is not set then a new directory will be created each time using mktemp.
I’ve had this script in use in a production environment for about five months with no apparent problems and I’ve tested it with newer versions of Firefox than are currently in SLED. Hopefully Firefox will one day support the XDG directory specification and then a wrapper script such as this will not be necessary, you can just set $XDG_CACHE_HOME and be done with it. (I already set $XDG_CACHE_HOME to somewhere outside the user’s home directory, hence why this wrapper scripts makes use of it if it’s set.) The bugzilla entries for such support were raised some years ago though so I’m not expecting such support to appear any time soon.