Rename cleanup: Old "VFS4G" now "Scalar"

When doing the rename, I converted all instances of "VFS" to "Scalar"
without first replacing the string "VFS4G". This left a bunch of
"Scalar4G" instances around the codebase. Fix that using the same
replace logic as before.

Signed-off-by: Derrick Stolee <[email protected]>

Author: derrickstolee

AuthoringTests.md

@@ -31,7 +31,7 @@ The functional tests are built on NUnit 3, which is available as a set of NuGet
 
     **Option 2:** Run `Scripts\BuildScalarForWindows.bat` from the command line
 
-2. Run the Scalar4G installer that was built in step 2.  This will ensure that Scalar4G will be able to find the correct version of the pre/post-command hooks. The installer will be placed in `BuildOutput\Scalar.Installer.Windows\bin\x64\<Debug or Release>`
+2. Run the Scalar installer that was built in step 2.  This will ensure that Scalar will be able to find the correct version of the pre/post-command hooks. The installer will be placed in `BuildOutput\Scalar.Installer.Windows\bin\x64\<Debug or Release>`
 3. Run the tests **with elevation**.  Elevation is required because the functional tests create and delete a test service.
 
    **Option 1:** Run the `Scalar.FunctionalTests.Windows` project from inside Visual Studio launched as Administrator.

CONTRIBUTING.md

@@ -45,23 +45,23 @@ The design review process is as follows:
 
 ## Tracing and Logging
 
-- *The "Error" logging level is reserved for non-retryable errors that result in I/O failures or the Scalar4G process shutting down*
+- *The "Error" logging level is reserved for non-retryable errors that result in I/O failures or the Scalar process shutting down*
 
-  The expectation from our customers is that when Scalar4G logs an "Error" level message in its log file either:
-    * Scalar4G had to shut down unexpectedly
-    * Scalar4G encountered an issue severe enough that user-initiated I/O would fail.
+  The expectation from our customers is that when Scalar logs an "Error" level message in its log file either:
+    * Scalar had to shut down unexpectedly
+    * Scalar encountered an issue severe enough that user-initiated I/O would fail.
 
 - *Log full exception stacks*
 
   Full exception stacks (i.e. `Exception.ToString`) provide more details than the exception message alone (`Exception.Message`). Full exception stacks make root-causing issues easier.
 
 - *Do not display full exception stacks to users*
 
-  Exception call stacks are not usually actionable for the user.  Users frequently (sometimes incorrectly) assume that Scalar4G has crashed when shown a full stack.  The full stack *should* be included in Scalar4G logs, but *should not* be displayed as part of the error message provided to the user.
+  Exception call stacks are not usually actionable for the user.  Users frequently (sometimes incorrectly) assume that Scalar has crashed when shown a full stack.  The full stack *should* be included in Scalar logs, but *should not* be displayed as part of the error message provided to the user.
 
 - *Include relevant details when logging exceptions*
 
-  Sometimes an exception call stack alone is not enough to root cause failures in Scalar4G.  When catching (or throwing) exceptions, log relevant details that will help diagnose the issue.  As a general rule, the closer an exception is caught to where it's thrown, the more relevant details there will be to log.
+  Sometimes an exception call stack alone is not enough to root cause failures in Scalar.  When catching (or throwing) exceptions, log relevant details that will help diagnose the issue.  As a general rule, the closer an exception is caught to where it's thrown, the more relevant details there will be to log.
 
   Example:
   ```
@@ -78,9 +78,9 @@ The design review process is as follows:
 
 ## Error Handling
 
-- *Fail fast: An error or exception that risks data loss or corruption should shut down Scalar4G immediately*
+- *Fail fast: An error or exception that risks data loss or corruption should shut down Scalar immediately*
 
-  Preventing data loss and repository corruption is critical.  If an error or exception occurs that could lead to data loss, it's better to shut down Scalar4G than keep the repository mounted and risk corruption.
+  Preventing data loss and repository corruption is critical.  If an error or exception occurs that could lead to data loss, it's better to shut down Scalar than keep the repository mounted and risk corruption.
 
 - *Do not catch exceptions that are indicative of a programmer error (e.g. `ArgumentNullException`)*
 
@@ -90,7 +90,7 @@ The design review process is as follows:
 
 - *Do not use exceptions for normal control flow*
 
-  Prefer writing code that does not throw exceptions.  The `TryXXX` pattern, for example, avoids the performance costs that come with using exceptions.  Additionally, Scalar4G typically needs to know exactly where errors occur and handle the errors there.  The `TryXXX` pattern helps ensure errors are handled in that fashion.
+  Prefer writing code that does not throw exceptions.  The `TryXXX` pattern, for example, avoids the performance costs that come with using exceptions.  Additionally, Scalar typically needs to know exactly where errors occur and handle the errors there.  The `TryXXX` pattern helps ensure errors are handled in that fashion.
 
   Example: Handle errors where they occur (good):
 
@@ -171,36 +171,36 @@ The design review process is as follows:
 
 - *Avoid using the thread pool (and avoid using async)*
 
-  `HttpRequestor.SendRequest` makes a [blocking call](https://github.com/Microsoft/Scalar/blob/4baa37df6bde2c9a9e1917fc7ce5debd653777c0/Scalar/Scalar.Common/Http/HttpRequestor.cs#L135) to `HttpClient.SendAsync`.  That blocking call consumes a thread from the managed thread pool.  Until that design changes, the rest of Scalar4G must avoid using the thread pool unless absolutely necessary.  If the thread pool is required, any long running tasks should be moved to a separate thread managed by Scalar4G itself (see [GitMaintenanceQueue](https://github.com/Microsoft/Scalar/blob/4baa37df6bde2c9a9e1917fc7ce5debd653777c0/Scalar/Scalar.Common/Maintenance/GitMaintenanceQueue.cs#L19) for an example).
+  `HttpRequestor.SendRequest` makes a [blocking call](https://github.com/Microsoft/Scalar/blob/4baa37df6bde2c9a9e1917fc7ce5debd653777c0/Scalar/Scalar.Common/Http/HttpRequestor.cs#L135) to `HttpClient.SendAsync`.  That blocking call consumes a thread from the managed thread pool.  Until that design changes, the rest of Scalar must avoid using the thread pool unless absolutely necessary.  If the thread pool is required, any long running tasks should be moved to a separate thread managed by Scalar itself (see [GitMaintenanceQueue](https://github.com/Microsoft/Scalar/blob/4baa37df6bde2c9a9e1917fc7ce5debd653777c0/Scalar/Scalar.Common/Maintenance/GitMaintenanceQueue.cs#L19) for an example).
 
-  Long-running or blocking work scheduled on the managed thread pool can prevent the normal operation of Scalar4G.  For example, it could prevent downloading file sizes, loose objects, or file contents in a timely fashion.
+  Long-running or blocking work scheduled on the managed thread pool can prevent the normal operation of Scalar.  For example, it could prevent downloading file sizes, loose objects, or file contents in a timely fashion.
 
 - <a id="bgexceptions"></a>*Catch all exceptions on long-running tasks and background threads*
 
-  Wrap all code that runs in the background thread in a top-level `try/catch(Exception)`.  Any exceptions caught by this handler should be logged, and then Scalar4G should be forced to terminate with `Environment.Exit`.  It's not safe to allow Scalar4G to continue to run after an unhandled exception stops a background thread or long-running task.  Testing has shown that `Environment.Exit` consistently terminates the Scalar4G mount process regardless of how background threads are started (e.g. native thread, `new Thread()`, `Task.Factory.StartNew()`).
+  Wrap all code that runs in the background thread in a top-level `try/catch(Exception)`.  Any exceptions caught by this handler should be logged, and then Scalar should be forced to terminate with `Environment.Exit`.  It's not safe to allow Scalar to continue to run after an unhandled exception stops a background thread or long-running task.  Testing has shown that `Environment.Exit` consistently terminates the Scalar mount process regardless of how background threads are started (e.g. native thread, `new Thread()`, `Task.Factory.StartNew()`).
 
   An example of this pattern can be seen in [`BackgroundFileSystemTaskRunner.ProcessBackgroundTasks`](https://github.com/Microsoft/Scalar/blob/4baa37df6bde2c9a9e1917fc7ce5debd653777c0/Scalar/Scalar.Virtualization/Background/BackgroundFileSystemTaskRunner.cs#L233).
 
 ## Coding Conventions
 
 - *Most C# coding style guidelines are covered by StyleCop*
 
-  Fix any StyleCop issues reported in changed code. When adding new projects to Scalar4G, be sure that StyleCop is analyzing them as part of the build.
+  Fix any StyleCop issues reported in changed code. When adding new projects to Scalar, be sure that StyleCop is analyzing them as part of the build.
 
 - *Prefer explicit types to interfaces and implicitly typed variables*
 
   Avoid the use of `var` (C#), `dynamic` (C#), and `auto` (C++).  Prefer concrete/explicit types to interfaces (e.g. prefer `List` to `IList`).
 
-  The Scalar4G codebase uses this approach because:
+  The Scalar codebase uses this approach because:
 
     * Interfaces can hide the performance characteristics of their underlying type.  For example, an `IDictionary` could be a `SortedList` or a `Dictionary` (or several other data types).
     * Interfaces can hide the thread safety (or lack thereof) of their underlying type.  For example, an `IDictionary` could be a `Dictionary` or a `ConcurrentDictionary`.
     * Explicit types make these performance and thread safety characteristics explicit when reviewing code.
-    * Scalar4G is not a public API and its components are always shipped together.  Develoepers are free to make API changes to Scalar4G's public methods.
+    * Scalar is not a public API and its components are always shipped together.  Develoepers are free to make API changes to Scalar's public methods.
 
 - *Method names start with a verb (e.g. "GetProjectedFolderEntryData" rather than "ProjectedFolderEntryData")*
 
-  Starting with a verb in the name improves readability and helps ensure consistency with the rest of the Scalar4G codebase.
+  Starting with a verb in the name improves readability and helps ensure consistency with the rest of the Scalar codebase.
 
 - *Aim to write self-commenting code.  When necessary, comments should give background needed to understand the code.*
 
@@ -226,7 +226,7 @@ The design review process is as follows:
 
 - *Add new interfaces when it makes sense for the product, not simply for unit testing*
 
-  When a class needs to be mocked (or have a subset of its behavior mocked), prefer using virtual methods instead of adding a new interface.  Scalar4G uses interfaces when multiple implementations of the interface exist in the product code.
+  When a class needs to be mocked (or have a subset of its behavior mocked), prefer using virtual methods instead of adding a new interface.  Scalar uses interfaces when multiple implementations of the interface exist in the product code.
 
 - *Check for `null` using the equality (`==`) and inequality (`!=`) operators rather than `is`*
 
@@ -279,7 +279,7 @@ The design review process is as follows:
 
   Comprehensive tests are essential for maintaining the health and quality of the product.  For more details on writing tests see [Authoring Tests](https://github.com/Microsoft/Scalar/blob/master/AuthoringTests.md).
 
-- *Functional tests are black-box tests and should not build against any Scalar4G product code*
+- *Functional tests are black-box tests and should not build against any Scalar product code*
 
   Keeping the code separate helps ensure that bugs in the product code do not compromise the integrity of the functional tests.
 

Protocol.md

@@ -1 +1 @@
-See Protocol.md in microsoft/vfsforgit.
+See Protocol.md in microsoft/vfsforgit.

Scalar.Common/ScalarPlatform.cs

@@ -45,13 +45,13 @@ public static void Register(ScalarPlatform platform)
         /// This method should only be called by processes whose code we own as the background process must
         /// do some extra work after it starts.
         /// </remarks>
-        public abstract void StartBackgroundScalar4GProcess(ITracer tracer, string programName, string[] args);
+        public abstract void StartBackgroundScalarProcess(ITracer tracer, string programName, string[] args);
 
         /// <summary>
         /// Adjusts the current process for running in the background.
         /// </summary>
         /// <remarks>
-        /// This method should be called after starting by processes launched using <see cref="ScalarPlatform.StartBackgroundScalar4GProcess"/>
+        /// This method should be called after starting by processes launched using <see cref="ScalarPlatform.StartBackgroundScalarProcess"/>
         /// </remarks>
         /// <exception cref="Win32Exception">
         /// Failed to prepare process to run in background.

Scalar.FunctionalTests/Tests/EnlistmentPerFixture/ScalarUpgradeReminderTests.cs

@@ -66,9 +66,9 @@ public void NoReminderForLeftOverDownloads()
 
             // This test should not use Nuget upgrader because it will usually find an upgrade
             // to download.  The "None" ring config doesn't stop the Nuget upgrader from checking
-            // its feed for updates, and the Scalar4G binaries installed during functional test
+            // its feed for updates, and the Scalar binaries installed during functional test
             // runs typically have a 0.X version number (meaning there will always be a newer
-            // version of Scalar4G available to download from the feed).
+            // version of Scalar available to download from the feed).
             this.ReadNugetConfig(out string feedUrl, out string feedName);
             this.DeleteNugetConfig();
             this.VerifyUpgradeVerbStopsReminder();

Scalar.Mount/InProcessMountVerb.cs

@@ -82,7 +82,7 @@ public void Execute()
         {
             if (this.StartedByVerb)
             {
-                // If this process was started by a verb it means that StartBackgroundScalar4GProcess was used
+                // If this process was started by a verb it means that StartBackgroundScalarProcess was used
                 // and we should be running in the background.  PrepareProcessToRunInBackground will perform
                 // any platform specific preparation required to run as a background process.
                 ScalarPlatform.Instance.PrepareProcessToRunInBackground();

Scalar.Platform.POSIX/POSIXPlatform.cs

@@ -53,7 +53,7 @@ public override void IsServiceInstalledAndRunning(string name, out bool installe
             throw new NotImplementedException();
         }
 
-        public override void StartBackgroundScalar4GProcess(ITracer tracer, string programName, string[] args)
+        public override void StartBackgroundScalarProcess(ITracer tracer, string programName, string[] args)
         {
             string programArguments = string.Empty;
             try
@@ -75,7 +75,7 @@ public override void StartBackgroundScalar4GProcess(ITracer tracer, string progr
                 // way to ensure they're properly closed.
                 //
                 // Note that this approach requires that the child process know that it needs to redirect its standard input/output to /dev/null and
-                // so this method can only be used with Scalar4G processes that are aware they're being launched in the background
+                // so this method can only be used with Scalar processes that are aware they're being launched in the background
                 processInfo.RedirectStandardError = true;
                 processInfo.RedirectStandardInput = true;
                 processInfo.RedirectStandardOutput = true;

Scalar.Platform.Windows/WindowsPlatform.cs

@@ -141,7 +141,7 @@ public override string GetDataRootForScalarComponent(string componentName)
             return WindowsPlatform.GetDataRootForScalarComponentImplementation(componentName);
         }
 
-        public override void StartBackgroundScalar4GProcess(ITracer tracer, string programName, string[] args)
+        public override void StartBackgroundScalarProcess(ITracer tracer, string programName, string[] args)
         {
             string programArguments = string.Empty;
             try

Scalar.Service/ScalarService.Windows.cs

@@ -249,7 +249,7 @@ private void CreateAndConfigureProgramDataDirectories()
             Directory.CreateDirectory(this.serviceDataLocation, serviceDataRootSecurity);
             Directory.CreateDirectory(ProductUpgraderInfo.GetUpgradeProtectedDataDirectory(), serviceDataRootSecurity);
 
-            // Ensure the ACLs are set correctly on any files or directories that were already created (e.g. after upgrading Scalar4G)
+            // Ensure the ACLs are set correctly on any files or directories that were already created (e.g. after upgrading Scalar)
             Directory.SetAccessControl(serviceDataRootPath, serviceDataRootSecurity);
 
             // Special rules for the upgrader logs, as non-elevated users need to be be able to write

Scalar.UnitTests/Mock/Common/MockPlatform.cs

@@ -141,7 +141,7 @@ public override bool TryGetDefaultLocalCacheRoot(string enlistmentRoot, out stri
             throw new NotImplementedException();
         }
 
-        public override void StartBackgroundScalar4GProcess(ITracer tracer, string programName, string[] args)
+        public override void StartBackgroundScalarProcess(ITracer tracer, string programName, string[] args)
         {
             throw new NotSupportedException();
         }

Scalar/CommandLine/MountVerb.cs

@@ -238,7 +238,7 @@ private bool TryMount(ITracer tracer, ScalarEnlistment enlistment, string mountE
 
             tracer.RelatedInfo($"{nameof(this.TryMount)}: Launching background process('{mountExecutableLocation}') for {enlistment.EnlistmentRoot}");
 
-            ScalarPlatform.Instance.StartBackgroundScalar4GProcess(
+            ScalarPlatform.Instance.StartBackgroundScalarProcess(
                 tracer,
                 mountExecutableLocation,
                 new[]