Closed Bug 216204 Opened 18 years ago Closed 16 years ago
Mac OS X disk cache should use ~/Library/Cache
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030814 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030814 Here at CMU, we have a network of various types of workstations (Windows, Mac, Linux, Solaris) in labs called "clusters". We use the OpenAFS file system to implement roaming profiles on Mac and Unix. On our Mac OS X machines, the home directory is local (so the desktop is local), but the Library folder is symlinked into AFS (along with another symlink to point users saving files into AFS). This setup has worked very well for us for over a year, but it presents a unique management problem; most software works fine in this environment, but none was designed for it. One difficulty is that we don't want temporary data such as web browser caches stored in AFS, for both disk space and performance reasons. Thus we symlink Library/Caches back into local disk, which takes care of that problem for Internet Explorer and Safari. Both of those browsers follow the ad hoc, de facto standard of using Library/Caches for cache; Apple doesn't actually list that directory in their System Overview for some reason. However, our priority for browser support is Netscape 7 (and in the future, some variant of Mozilla) -- MSIE is being phased out upstream with no likely replacement, it is slow, and it has never had proper certificate handling for our local CA, among many other issues with it. Safari currently lacks polish, and we haven't made any commitment on that yet. Currently, we use a kludge which has worked just fine for over a year to make Netscape save its cache locally. We set up a set of ns/moz prefs using a test account with the home directory /Users/CurrentUser, and set the cache to a well-defined local disk location within that home directory. The LoginHook on cluster machines ensures that these prefs are installed in user accounts if they don't exist or have been corrupted, and it also makes sure that /Users/CurrentUser is a symlink to the I would like to avoid some of this hassle in the future, however. I understand that making moz cache handling work like IE/safari would compromise a lot of flexibility; however, the Caches directory is there for a reason, and it is very convenient and clean to be able to just symlink that locally and have many applications store temporary data on local disk rather than on the network. Some suggestions: 1. It might be nice if moz could handle home directory relative cache location, so that preferences moved from account to account would work without kludges like /Users/CurrentUser. [This is not a Mac-specific concept, but on Unix we're afforded the luxury of user-specific mozilla startup scripts, which set up the cache location automatically. We can't do this on the mac because we want the application launch itself to work without a wrapper script; in addition, the cache is stored as a base64-encoded structure in the prefs file which makes manipulating it more difficult.] 2. Moz could have a "default cache" on the mac and if the cache location is left blank it would use this location. This could use the preferences salt as a directory name within the Caches folder, so multiple profiles would still work. Just some ideas... Reproducible: Always Steps to Reproduce:
In paragraph 4 above, last sentence should read "...it also makes sure that /Users/CurrentUser is a symlink to the home directory of the user logged in on console."
Reporter, doesn't the preference 'browser.cache.disk.parent_directory' help ? See bug 78480 comment 43. Use about:config to change that. I agree that it would be nice to store the cache-files by default in the standard Mac location (~/Library/Caches). Dupe of bug 74085 ?
Jo: We already set browser.cache.disk.parent_directory -- but since on the Mac it is a base64-encoded structure, we can't set it dynamically for each user, so we use one common location for everyone that's precalculated, and symlinks to fake it such that the location is always in the current user's home directory.
Does anyone know of we have a bug that requests we move to using a UNIX path for this pref? This is probably a CFM->Mach-O issue that I never really had time to think about?
This omission also confuses the Retrospect backup, which is designed to ignore ~/Library/Caches by default. It is in addition a problem with Camino as well.
(In reply to comment #4) > Does anyone know of we have a bug that requests we move to using a UNIX path for > this pref? I filed that one as bug 217146 > This is probably a CFM->Mach-O issue that I never really had time to think about?
-> defaults. I'm trying to push for re-thinking the location of cache for each platform.
Summary: Mac mozilla cache is in the "wrong" place → Mac OS X disk cache should use ~/Library/Cache
Should there be similar bugs for Camino and Firefox or will a fix of this bug (changing the default location) also affect them?
Once mailnews irons out profile relative paths, we should just switch to using that (which entails a new preference anyway) for the cache folder.
*** Bug 239284 has been marked as a duplicate of this bug. ***
*** Bug 289098 has been marked as a duplicate of this bug. ***
This is very similar to bug 74085. The solution for that bug could be used to fix this bug.
Assignee: gordon → darin
Depends on: 74085
Target Milestone: --- → mozilla1.8beta2
This bug is fixed now with the patch for bug 291033.
(In reply to comment #13) > This bug is fixed now with the patch for bug 291033. Yep, I can see that the Cache-folder and the fastload file (XUL.mfasl) are really in the ~/Library/Cache folder. It's salted exactly like the profile. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050426 Firefox/1.0+
In Camino, ~/Library/Cache has not been used yet. 20050426 nightly build and Camino that does build for myself now 2005042722 (v0.8+)
> In Camino, ~/Library/Cache has not been used yet. That's right; Camino wasn't fixed. Someone should file a separate bug on Camino.
Bug 239284 is specific to Camino, it was filed already a while ago.
You need to log in before you can comment on or make changes to this bug.