Shorten SingletonSocket filename, makes socket length limit harder to hit.

chrome/browser/process_singleton_posix.cc

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // On Linux, when the user tries to launch a second copy of chrome, we check
 // for a socket in the user's profile directory.  If the socket file is open we
 // send a message to the first chrome browser process with the current
 // directory and second process command line flags.  The second process then
 // exits.
 //
@@ skipping 701 matching lines @@
 
 ///////////////////////////////////////////////////////////////////////////////
 // ProcessSingleton
 //
 ProcessSingleton::ProcessSingleton(
     const base::FilePath& user_data_dir,
     const NotificationCallback& notification_callback)
     : notification_callback_(notification_callback),
       current_pid_(base::GetCurrentProcId()),
       watcher_(new LinuxWatcher(this)) {
   socket_path_ = user_data_dir.Append(chrome::kSingletonSocketFilename);

[Nico, 2017/03/17 19:31:49]

Why does this one keep using the old path? Why not just change the contents of
kSingletonSocketFilename? Having two paths for this seems confusing, and
apparently no tests need updating, so there aren't any tests that explain why
one place uses one name and another the other.

[mattm, 2017/03/17 22:20:18]

(I did mention in the CL description, let me know if that isn't sufficient.)
There are two places the names come up since one is the name of the symlink in
the userdatadir, and the other is the actual name of the socket file.
I wanted to leave the name of the file in the userdata dir as the longer version
just so it's less confusing. Only the length of the actual socket file's name
matters. Does that seem reasonable, or do yo u think having them both be the
short version would be cleaner?

Re: tests, since it's currently a CHECK on the file length it's not easy to
test.. but maybe it would be good to have a more user-friendly  error anyway? It
seems like on mac even if you run from the console you don't see the CHECK
failure message..

   lock_path_ = user_data_dir.Append(chrome::kSingletonLockFilename);
   cookie_path_ = user_data_dir.Append(chrome::kSingletonCookieFilename);
 
   kill_callback_ = base::Bind(&ProcessSingleton::KillProcess,
                               base::Unretained(this));
 }
 
 ProcessSingleton::~ProcessSingleton() {
 }
 
@@ skipping 244 matching lines @@
   }
 
   // Check that the directory was created with the correct permissions.
   int dir_mode = 0;
   CHECK(base::GetPosixFilePermissions(socket_dir_.GetPath(), &dir_mode) &&
         dir_mode == base::FILE_PERMISSION_USER_MASK)
       << "Temp directory mode is not 700: " << std::oct << dir_mode;
 
   // Setup the socket symlink and the two cookies.
   base::FilePath socket_target_path =
-      socket_dir_.GetPath().Append(chrome::kSingletonSocketFilename);
+      socket_dir_.GetPath().Append(chrome::kSingletonSocketRealFilename);
   base::FilePath cookie(GenerateCookie());
   base::FilePath remote_cookie_path =
       socket_dir_.GetPath().Append(chrome::kSingletonCookieFilename);
   UnlinkPath(socket_path_);
   UnlinkPath(cookie_path_);
   if (!SymlinkPath(socket_target_path, socket_path_) ||
       !SymlinkPath(cookie, cookie_path_) ||
       !SymlinkPath(cookie, remote_cookie_path)) {
     // We've already locked things, so we can't have lost the startup race,
     // but something doesn't like us.
@@ skipping 66 matching lines @@
 }
 
 void ProcessSingleton::KillProcess(int pid) {
   // TODO(james.su@gmail.com): Is SIGKILL ok?
   int rv = kill(static_cast<base::ProcessHandle>(pid), SIGKILL);
   // ESRCH = No Such Process (can happen if the other process is already in
   // progress of shutting down and finishes before we try to kill it).
   DCHECK(rv == 0 || errno == ESRCH) << "Error killing process: "
                                     << base::safe_strerror(errno);
 }