summaryrefslogtreecommitdiffstats
path: root/base/path_service.h
Commit message (Collapse)AuthorAgeFilesLines
* windows: remove PathService::Get() that uses wstringsevan@chromium.org2010-11-301-5/+0
| | | | | | | | | | This just required fixing the remaining callers. BUG=24672 Review URL: http://codereview.chromium.org/5356008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67783 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 67201 - Revert 67191 - chrome_paths: refactor and sanitize cache ↵viettrungluu@chromium.org2010-11-241-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | directory handling [Checking to see if this build failures on Windows.] [[Nope. Failure was a flake.]] 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 TBR=evan@chromium.org Review URL: http://codereview.chromium.org/5344003 TBR=viettrungluu@chromium.org git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67202 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 67191 - chrome_paths: refactor and sanitize cache directory handlingviettrungluu@chromium.org2010-11-241-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Checking to see if this build failures on Windows.] 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 TBR=evan@chromium.org Review URL: http://codereview.chromium.org/5344003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67201 0039d316-1c4b-4281-b951-d872f2087c98
* chrome_paths: refactor and sanitize cache directory handlingevan@chromium.org2010-11-241-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "chrome_paths: refactor and sanitize cache directory handling"evan@chromium.org2010-11-231-0/+5
| | | | | | This reverts commit r67160, test failures. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67171 0039d316-1c4b-4281-b951-d872f2087c98
* chrome_paths: refactor and sanitize cache directory handlingevan@chromium.org2010-11-231-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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@67160 0039d316-1c4b-4281-b951-d872f2087c98
* linux: fix cache corruption when using multiple --user-data-direvan@chromium.org2010-11-131-0/+5
| | | | | | | | | | | | | | This regressed in r59021. I think I can fix it in a cleaner way with some refactoring, but for now since I want to cherry-pick this onto older branches let's revert some of r59021 to fix this in the simplest way possible. BUG=59824 TEST=manual (will write a test in my followup that refactors it) Review URL: http://codereview.chromium.org/4911002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66066 0039d316-1c4b-4281-b951-d872f2087c98
* Fix CheckFalseTest.CheckFails on Linux after my change to ui_test.phajdan.jr@chromium.org2010-09-091-3/+1
| | | | | | | | | | | | | This makes PathService clear its cache after overriding a path. We have many paths depending on each other, so this is necessary to avoid inconsistencies. TEST=ui_tests in Release mode BUG=49838 Review URL: http://codereview.chromium.org/2805100 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59021 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 56738 - Fix CheckFalseTest.CheckFails on Linux after my change to ↵rvargas@google.com2010-08-191-1/+3
| | | | | | | | | | | | | | | | | | ui_test. This makes PathService clear its cache after overriding a path. We have many paths depending on each other, so this is necessary to avoid inconsistencies. TEST=ui_tests in Release mode BUG=49838 Review URL: http://codereview.chromium.org/2805100 TBR=phajdan.jr@chromium.org Review URL: http://codereview.chromium.org/3169031 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56778 0039d316-1c4b-4281-b951-d872f2087c98
* Fix CheckFalseTest.CheckFails on Linux after my change to ui_test.phajdan.jr@chromium.org2010-08-191-3/+1
| | | | | | | | | | | | | This makes PathService clear its cache after overriding a path. We have many paths depending on each other, so this is necessary to avoid inconsistencies. TEST=ui_tests in Release mode BUG=49838 Review URL: http://codereview.chromium.org/2805100 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56738 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 55450 - Fix CheckFalseTest.CheckFails on Linux after my change to ↵glen@chromium.org2010-08-091-1/+3
| | | | | | | | | | | | | | | | | | | | | ui_test. This makes PathService clear its cache after overriding a path. We have many paths depending on each other, so this is necessary to avoid inconsistencies. Added a comment that PathService::Override should not be called by production code. TEST=ui_tests in Release mode BUG=49838 Review URL: http://codereview.chromium.org/2805100 TBR=phajdan.jr@chromium.org Review URL: http://codereview.chromium.org/3107001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55468 0039d316-1c4b-4281-b951-d872f2087c98
* Fix CheckFalseTest.CheckFails on Linux after my change to ui_test.phajdan.jr@chromium.org2010-08-091-3/+1
| | | | | | | | | | | | | | | | This makes PathService clear its cache after overriding a path. We have many paths depending on each other, so this is necessary to avoid inconsistencies. Added a comment that PathService::Override should not be called by production code. TEST=ui_tests in Release mode BUG=49838 Review URL: http://codereview.chromium.org/2805100 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55450 0039d316-1c4b-4281-b951-d872f2087c98
* `#pragma once` for app, base, chrome, gfx, ipc, net, skia, viewsthakis@chromium.org2010-07-261-0/+1
| | | | | | | | | BUG=50273 TEST=everything still builds, build is 10% faster on windows, same speed on mac/linux TBR: erg git-svn-id: svn://svn.chromium.org/chrome/trunk/src@53716 0039d316-1c4b-4281-b951-d872f2087c98
* Deprecate PathService::Get(..., wstring*) and use FilePath instead.evan@chromium.org2009-10-191-0/+2
| | | | | | | | | | | | I tried fixing all the Windows code but there's a *ton* of it. This change will at least prevent people from adding new code that uses the deprecated version (as that won't compile on Lin/Mac). BUG=24672 Review URL: http://codereview.chromium.org/293013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29472 0039d316-1c4b-4281-b951-d872f2087c98
* Quick fix to use file_util::SetCurrentDirectory method instead of the ↵erikkay@chromium.org2009-09-161-11/+0
| | | | | | | | | | | | PathService method, also avoids the conflict with the the windows function. BUG=None TEST=None Review URL: http://codereview.chromium.org/196072 Patch from thiago.farina@gmail.com. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26351 0039d316-1c4b-4281-b951-d872f2087c98
* Landing the patch of Thiago Farina.jcampan@chromium.org2009-09-021-7/+3
| | | | | | | | | | | | | See http://codereview.chromium.org/183025 Removes the deprecated version of PathService::Override that uses std::wstring and fix the callers. BUG=None TEST=None Review URL: http://codereview.chromium.org/185007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25185 0039d316-1c4b-4281-b951-d872f2087c98
* On Linux, the path to the exe is used to fork renderer processes.jcampan@chromium.org2009-06-251-0/+3
| | | | | | | | | | | This was causing the browser tests to create browser tests instead of a renderer processes. Also the SSL tests now pass on Linux and have been enabled. BUG=None TEST=Run the browser tests on Linux. Review URL: http://codereview.chromium.org/146057 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19257 0039d316-1c4b-4281-b951-d872f2087c98
* NO CODE CHANGEdeanm@chromium.org2009-03-101-1/+0
| | | | | | | | | Normalize end of file newlines in base/. All files end in a single newline. Review URL: http://codereview.chromium.org/42011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11329 0039d316-1c4b-4281-b951-d872f2087c98
* NO CODE CHANGE (except one global std::wstring changed to const wchar_t* ↵maruel@chromium.org2009-03-031-2/+3
| | | | | | | | | | | const per style compliance). Preliminary work to enforce new PRESUBMIT.py rules: - <=80 cols - no trailing whitespaces - svn:eol-style=LF git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10791 0039d316-1c4b-4281-b951-d872f2087c98
* Move more code to using FilePath.evanm@google.com2008-11-191-1/+1
| | | | | | | Review URL: http://codereview.chromium.org/11252 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5679 0039d316-1c4b-4281-b951-d872f2087c98
* Begin the first small step towards using FilePath everywhere:evanm@google.com2008-10-301-2/+7
| | | | | | | | | | - Add some transition APIs. - Start migrating some code to transition APIs. Review URL: http://codereview.chromium.org/8825 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4254 0039d316-1c4b-4281-b951-d872f2087c98
* Use a more compact license header in source files.license.bot2008-08-241-28/+4
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98
* I accidentally committed file_version_info. Since comments were relatively ↵erikkay@google.com2008-08-121-1/+1
| | | | | | minor, I created a new CL rather than reverting the old one. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@722 0039d316-1c4b-4281-b951-d872f2087c98
* recursive_mutexerikkay@google.com2008-08-111-0/+4
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@650 0039d316-1c4b-4281-b951-d872f2087c98
* Refactoring file_util into file_util and file_util_win. Also fix windows ↵erikkay@google.com2008-08-061-0/+10
| | | | | | | | dependencies in path_service.cc. One questionable decision here was to put GetCurrentDirectory and SetCurrentDirectory into file_util_win.cc. I could have kept the logic in path_service.cc with #ifdefs or I could have split up path_service.cc into path_service_win.cc, etc. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@436 0039d316-1c4b-4281-b951-d872f2087c98
* Add base to the repository.initial.commit2008-07-261-0/+85
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-05 08:49:42 +0000