summaryrefslogtreecommitdiffstats
path: root/base/path_service_unittest.cc
Commit message (Collapse)AuthorAgeFilesLines
* Enforce no path service has improper path.maruel@chromium.org2013-01-251-0/+11
| | | | | | | | | R=cpu@chromium.org,mark@chromium.org BUG=168890 Review URL: https://chromiumcodereview.appspot.com/12035095 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@178932 0039d316-1c4b-4281-b951-d872f2087c98
* Move scoped_temp_dir from base to base/filesbrettw@chromium.org2012-11-161-6/+6
| | | | | | | | | | Also add to base namespace. BUG= Review URL: https://codereview.chromium.org/11359217 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@168281 0039d316-1c4b-4281-b951-d872f2087c98
* Fix style typo (missing space) in base/path_service_unittest.ccgab@chromium.org2012-11-151-1/+1
| | | | | | | | | | | NOTRY=True BUG=None TBR=willchan Review URL: https://chromiumcodereview.appspot.com/11359220 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@167801 0039d316-1c4b-4281-b951-d872f2087c98
* Re-commit: Introduce RemoveChromeTaskbarShortcuts() to delete all ↵gab@chromium.org2012-11-061-13/+22
| | | | | | | | | | | | | | pinned-to-taskbar shortcuts owned by the uninstalled Chrome. Original commit http://crrev.com/165505 Reverted in http://crrev.com/165524 BUG=158632 TEST=No user-level shortcut Chrome left behind in taskbar post user-level self-destruct. Review URL: https://chromiumcodereview.appspot.com/11368040 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166285 0039d316-1c4b-4281-b951-d872f2087c98
* Add PathService::RemoveOverride to clear path overrides.pastarmovj@chromium.org2012-09-261-0/+45
| | | | | | | | | | | | | | | This is especially useful for unit tests because they live in the same process and share all the singletons including PathService. One can of course override the overrides but it is much cleaner and sometimes the only good solution to return to the original PathProvider instead. BUG=149161 TEST=base_unittests:PathServiceTest.* Review URL: https://chromiumcodereview.appspot.com/10909228 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@158842 0039d316-1c4b-4281-b951-d872f2087c98
* Fix PathServiceTest.Get on iOS.rohitrao@chromium.org2012-09-251-0/+3
| | | | | | | | | | | | DIR_USER_DESKTOP does not apply on iOS, so exclude it from the set of paths that are tested. BUG=b/151050 Review URL: https://chromiumcodereview.appspot.com/10970019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@158607 0039d316-1c4b-4281-b951-d872f2087c98
* Add new PathService paths for Windows' All Users Desktop and Quick Launch ↵gab@chromium.org2012-09-201-9/+44
| | | | | | | | | | | | | | | | | | | | | | | folders. Re-commit, reverted in http://crrev.com/157680 (original commit in http://crrev.com/157667). This allows usage of PathService to cache the shortcut install paths and more importantly to mock them in shortcut tests! Also move chrome::DIR_USER_DESKTOP to base::DIR_USER_DESKTOP; this is really where it belongs. In fact it is only in chrome_paths.h because it used to be called DIR_DEFAULT_DOWNLOAD and cpu@ renamed it to DIR_USER_DESKTOP in http://crrev.com/1753 (early days!) after that it started to be used all over the place as the Desktop path. Finally bringing it to base_paths.h, beside DIR_START_MENU and friends, is the right thing to do imo. TBR=brettw@chromium.org BUG=148539 TEST=Quick Launch shortcut installed in the right place on XP (both Default and current user) Desktop shortcuts installed in the right place (both All Users and per-user installs). installer_util_unittests.exe --gtest_filter=ShellUtilShortcutTest* unit_tests.exe --gtest_filter=ProfileShortcutManagerTest* base_unittests --gtest_filter=PathServiceTest* Review URL: https://chromiumcodereview.appspot.com/10964007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@157779 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 157667 - Add new PathService paths for Windows' All Users Desktop and ↵wjia@chromium.org2012-09-201-27/+9
| | | | | | | | | | | | | | | | | | | | | | | | | Quick Launch folders. The previous patch failed PathServiceTest.Get. This allows usage of PathService to cache the paths and more importantly to mock them in shortcut tests! Also move chrome::DIR_USER_DESKTOP to base::DIR_USER_DESKTOP; this is really where it belongs. In fact it is only in chrome_paths.h because it used to be called DIR_DEFAULT_DOWNLOAD and cpu@ renamed it to DIR_USER_DESKTOP in http://crrev.com/1753 (early days!) after that it started to be used all over the place as the Desktop path. Finally bringing it to base_paths.h, beside DIR_START_MENU and friends, is the right thing to do imo. BUG=148539 TEST=Quick Launch shortcut installed in the right place on XP (both Default and current user) Desktop shortcuts installed in the right place (both All Users and per-user installs). installer_util_unittests.exe --gtest_filter=ShellUtilShortcutTest* unit_tests.exe --gtest_filter=ProfileShortcutManagerTest* base_unittests --gtest_filter=PathServiceTest* Review URL: https://chromiumcodereview.appspot.com/10910209 TBR=gab@chromium.org Review URL: https://codereview.chromium.org/10958009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@157680 0039d316-1c4b-4281-b951-d872f2087c98
* Add new PathService paths for Windows' All Users Desktop and Quick Launch ↵gab@chromium.org2012-09-201-9/+27
| | | | | | | | | | | | | | | | | | | | folders. This allows usage of PathService to cache the paths and more importantly to mock them in shortcut tests! Also move chrome::DIR_USER_DESKTOP to base::DIR_USER_DESKTOP; this is really where it belongs. In fact it is only in chrome_paths.h because it used to be called DIR_DEFAULT_DOWNLOAD and cpu@ renamed it to DIR_USER_DESKTOP in http://crrev.com/1753 (early days!) after that it started to be used all over the place as the Desktop path. Finally bringing it to base_paths.h, beside DIR_START_MENU and friends, is the right thing to do imo. BUG=148539 TEST=Quick Launch shortcut installed in the right place on XP (both Default and current user) Desktop shortcuts installed in the right place (both All Users and per-user installs). installer_util_unittests.exe --gtest_filter=ShellUtilShortcutTest* unit_tests.exe --gtest_filter=ProfileShortcutManagerTest* base_unittests --gtest_filter=PathServiceTest* Review URL: https://chromiumcodereview.appspot.com/10910209 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@157667 0039d316-1c4b-4281-b951-d872f2087c98
* Delete Chrome's secondary tiles on Windows 8 when uninstalling.benwells@chromium.org2012-08-301-9/+21
| | | | | | | | | | | The Windows secondary tiles deletion functions are only available to Chrome itself when running in metro mode. To get around this, the folder containing the installation's secondarty tiles is removed entirely. BUG=140559 Review URL: https://chromiumcodereview.appspot.com/10876057 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@154103 0039d316-1c4b-4281-b951-d872f2087c98
* Add new method OverrideAndCreateIfNeeded to PathService.pastarmovj@chromium.org2012-05-091-1/+26
| | | | | | | | | | | | This is prerequisite for adding support for running chrome on network shared location BUG=120388 TEST=base_unittests:PathServiceTest.Override Review URL: https://chromiumcodereview.appspot.com/10388027 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@136017 0039d316-1c4b-4281-b951-d872f2087c98
* Upstream misc changes for android.michaelbai@google.com2011-08-261-1/+5
| | | | | | | | | BUG= TEST= Review URL: http://codereview.chromium.org/7701014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@98432 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 67201 - Revert 67191 - chrome_paths: refactor and sanitize cache ↵viettrungluu@chromium.org2010-11-241-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+6
| | | | | | 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-6/+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
* If chromium has not been started yet, the cache path will not exist.maruel@chromium.org2010-10-231-0/+6
| | | | | | | | | TEST=Fix PathServiceTest.Get on POSIX on new slaves BUG=none Review URL: http://codereview.chromium.org/4023006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63649 0039d316-1c4b-4281-b951-d872f2087c98
* Move windows version-related stuff out of base/win_util and into ↵brettw@chromium.org2010-10-151-3/+3
| | | | | | | | | | | | | | base/win/windows_version. Many files now only need to include this instead of all of win_util. Remove a bunch of unused code from base/win_util. There was a surprising amount. Replace the AppUserModel property key with the one from the SDK now that we use the Win7 SDK. Move GetLogonSessionOnlyDACL from win_util to ipc since it's only used in that one place. TEST=it compiles BUG=none Review URL: http://codereview.chromium.org/3823002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@62694 0039d316-1c4b-4281-b951-d872f2087c98
* Set OS X cache directory to ~/Library/Caches/[app name]/[profile name] mark@chromium.org2009-09-161-1/+5
| | | | | | | | | | | | | - Added implementation of GetUserCacheDirectory() for OS X. - Added FilePath::GetRelativePath(). - Implemented per-profile cache directories for OS X. Patch by Fred Akalin <akalin@gmail.com> Code review URL: http://codereview.chromium.org/174053 Review URL: http://codereview.chromium.org/204043 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26387 0039d316-1c4b-4281-b951-d872f2087c98
* Fix to use FilePath in more unittests.phajdan.jr@chromium.org2009-09-141-1/+1
| | | | | | | | | | | Landing patch for Thiago Farina, original review: http://codereview.chromium.org/187005 BUG=None TEST=run unit_tests.exe, base_unittests.exe. Review URL: http://codereview.chromium.org/193101 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26142 0039d316-1c4b-4281-b951-d872f2087c98
* Remove logging.h from cc files that don't use it.thestig@chromium.org2009-03-121-1/+0
| | | | | | Review URL: http://codereview.chromium.org/42155 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11593 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
* * Cleanup: move base/platform_test.h -> testing/jeremy@chromium.org2008-12-021-1/+1
| | | | | | | | * Add support for "Debug On Start" switch to MultiprocessTest::SpawnChild Review URL: http://codereview.chromium.org/13052 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6227 0039d316-1c4b-4281-b951-d872f2087c98
* Begin the first small step towards using FilePath everywhere:evanm@google.com2008-10-301-3/+5
| | | | | | | | | | - 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
* Create a gtest test fixture subclass that allows for platform specific setup ↵erikkay@google.com2008-08-201-1/+6
| | | | | | and teardown hooks. On the Mac use this to create an outer Autorelease pool. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1089 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
* Remove a NOTREACHED() that was causing a dialog box during unit tests, hencemaruel@google.com2008-08-071-10/+4
| | | | | | making it timeout on the test bot. Also simplify the test code. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@546 0039d316-1c4b-4281-b951-d872f2087c98
* Improve PathServiceTest test by verifying that the returned path exists.maruel@google.com2008-08-071-5/+26
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@533 0039d316-1c4b-4281-b951-d872f2087c98
* Refactoring file_util into file_util and file_util_win. Also fix windows ↵erikkay@google.com2008-08-061-0/+5
| | | | | | | | 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/+57
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-04-02 18:38:09 +0000