Fix the new First Run sentinel file path determination.

chrome/installer/setup/install.cc

Index: chrome/installer/setup/install.cc
diff --git a/chrome/installer/setup/install.cc b/chrome/installer/setup/install.cc
index 078a9ac7ff60c2cdc9ba49783fe45547b16832f8..eb178b106f5c6052b8b232a6fdba4c75cc0c03cc 100644
--- a/chrome/installer/setup/install.cc
+++ b/chrome/installer/setup/install.cc
@@ -677,8 +677,9 @@ void HandleActiveSetupForBrowser(const base::FilePath& installation_root,
   // run and this could otherwise re-install shortcuts for users that have
   // already deleted them in the past).
   base::FilePath first_run_sentinel;
-  InstallUtil::GetSentinelFilePath(
-      chrome::kFirstRunSentinel, chrome.distribution(), &first_run_sentinel);
+  if (!PathService::Get(chrome::DIR_USER_DATA, &first_run_sentinel))

[grt (UTC plus 2), 2014/03/25 17:37:06]

i think you mean:
  if (PathService::Get(...))
    first_run_sentinel = first_run_sentinel.Append(chrome::kFirstRunSentinel);
but it's not clear to me what the right thing is for the else case. NOTREACHED
and early return?

on second thought, util/eula_util.cc has a "IsChromeFirstRunPending" method that
seems to answer exactly the question that's being asked in the code here. how
about making that function public and using it here (and anywhere else that does
something similar)?

[msw, 2014/03/25 23:33:13]

Good catch and recommendation. I've reorganized and consolidated the first run
sentinel code around InstallUtil. I double-checked the logic and tested
developer Chromium builds (with and without the sentinel at default and
overridden user-data-dirs), as well as Chrome branded mini_installer instances
installed with setup.exe --chrome and --chrome-sxs (also with default and
overridden user-data-dirs). I also ensured that making Chrome the default
browser on first run also removed the sentinel to show the first-run experience
on the re-launch, and ensured that both --force-first-run and --no-first-run
worked as expected. As far as I can tell, the first run sentinel is being
created at (or copied to) the correct locations and respected by the application
correctly.

I did not verify that environment variable or policy overrides of DIR_USER_DATA
worked as expected, but they're handled in the same function as the commandline
overrides that I tested, so they should work fine. I did not test scenarios with
mixed system-level and user-level installations, nor deprecated
kMetroChromeUserDataSubDir scenarios, and may have missed some other corner
cases, but on the whole I think this is much better than it was.

+    first_run_sentinel = first_run_sentinel.Append(chrome::kFirstRunSentinel);
+
   // Decide whether to create the shortcuts or simply replace existing
   // shortcuts; if the decision is to create them, only shortcuts whose matching
   // all-users shortcut isn't present on the system will be created.