summaryrefslogtreecommitdiffstats
path: root/base/path_service.h
diff options
context:
space:
mode:
authorevan@chromium.org <evan@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2010-11-24 01:06:40 +0000
committerevan@chromium.org <evan@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2010-11-24 01:06:40 +0000
commit8c619149607580303c4050ee908f22c08fcb697c (patch)
treea2f5647f391fb3d083a5cfd5dab1d1232169b0dd /base/path_service.h
parent54c833622553a4feff635400279619f339dad3dd (diff)
downloadchromium_src-8c619149607580303c4050ee908f22c08fcb697c.zip
chromium_src-8c619149607580303c4050ee908f22c08fcb697c.tar.gz
chromium_src-8c619149607580303c4050ee908f22c08fcb697c.tar.bz2
chrome_paths: refactor and sanitize cache directory handling
Previously we had a bunch of logic in profile_impl.cc that computed where the cache directory lives. This change relocates it to chrome_paths.cc. Some background on cache directories. There are two possible places to store cache files: 1) in the user data directory 2) in an OS-specific user cache directory On Windows, we always pick (1). On Mac and Linux, we currently use (2) in some circumstances. This patch changes both Mac and Linux to have the same behavior with respect to (2). The Mac/Linux shared behavior is that if the profile directory is in the standard location for profiles, we put the cache files into a matching directory name in the standard system cache directory (e.g. on Linux if you're using ~/.config/google-chrome, your cache ends up in ~/.cache/google-chrome; on Mac, the directories are ~/Library/Application Support versus ~/Library/Caches). If your user data directory is not in the standard location, we use behavior (1). The semantic changes of this patch should be: - On Mac, previously we checked whether the (2) directory had some particular subdirectories already when picking which one to use. This was removed; which directory is used is solely a question of whether the profile directory is in the standard location. I think the previous behavior was unpredictable. - On Linux, previously we only used behavior (2) if you hadn't changed your user-data-directory at all. Now, to match Mac, as long as your user-data-dir is in the standard place, you use the system cache dir. So e.g. using ~/.config/foobar puts your cache in ~/.cache/foobar. - On Linux, previously the default cache would end up as directories under ~/.cache/google-chrome/; now it ends up as directories under ~/.cache/google-chrome/Default/. (In all instances above, on Linux we continue to obey $XDG_CACHE_HOME.) BUG=59824 TEST=New test ChromePaths.UserCacheDir Review URL: http://codereview.chromium.org/5123004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67191 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'base/path_service.h')
-rw-r--r--base/path_service.h5
1 files changed, 0 insertions, 5 deletions
diff --git a/base/path_service.h b/base/path_service.h
index 6873e1f..4d99cdc 100644
--- a/base/path_service.h
+++ b/base/path_service.h
@@ -45,11 +45,6 @@ class PathService {
// over the lifetime of the app, so this method should be used with caution.
static bool Override(int key, const FilePath& path);
- // Return whether a path was overridden.
- // TODO(evan): temporarily restoring this to quick-fix a regression.
- // Remove me again once it's fixed properly.
- static bool IsOverridden(int key);
-
// To extend the set of supported keys, you can register a path provider,
// which is just a function mirroring PathService::Get. The ProviderFunc
// returns false if it cannot provide a non-empty path for the given key.