ProductUpgradeTimer: remove unacceptable Environment.Exit() #1668
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Derrick Stolee <[email protected]>
jeffhostetler
approved these changes
May 27, 2020
derrickstolee
added a commit
to microsoft/scalar
that referenced
this pull request
May 28, 2020
…r Git Scalar was created by forking the VFS for Git codebase, deleting a bunch of code, then renaming a bunch of files. It has since diverged significantly through many refactors. One thing that has _never worked_ is the `scalar upgrade` verb when using GitHub as the source. The reason is that we package our releases differently than VFS for Git does, so the upgrader fails to find the Git installer and Scalar installer (instead, we have two `.zip` files, one for each platform). Since we are moving to another system for the typical upgrade pattern, we should just delete the GitHub upgrader. The `scalar upgrade` verb will remain for the NuGet feed, when configured. This resolves #351. An issue was found in VFS for Git where the service would restart constantly when checking for an upgrade. The root cause was a problematic `Environment.Exit()` call. See microsoft/VFSForGit#1668 for an equivalent change. Another annoying thing is the verbose output during `scalar clone` that repeats the given options. In the case of a non-GVFS protocol clone, some of these just don't make sense. Delete this output for clarity. Finally, `scalar clone` failed miserably when using a non-standard URL such as `file://`. Fix that by doing some URL scanning in advance. If the URL does not start with `http://` or `https://`, we will not even try the GVFS protocol and will move on to a native Git clone. We also avoid any protocol prefix (`X://`) that is not `http://`, `https://` or `ssh://`. For SSH, the protocol prefix is not required, so we do not require a protocol prefix. Resolves #378. Since this is a grab-bag of things, please review commit-by-commit. For the GitHub upgrader removal, consider ignoring whitespace changes.
derrickstolee
added a commit
that referenced
this pull request
Jun 2, 2020
Includes the following pull requests: * #1663: Update Git to v2.27.0 * #1669: Docs: more troubleshooting and FAQs * #1668: ProductUPgradeTimer: remove unacceptable Environment.Exit() * #1664: Update USN journal entries for projected folders * #1666: Docs: start basic template * #1658: ProjFSFilter: Be more robust to missing PowerShell
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A user reported an issue via the Teams channel. Looking at the diagnose logs I saw that the user's
GVFS.Servicewas restarting in a loop with an exception tracking down to thisEnvironment.Exit()call.It's completely unacceptable to exit here, as it kills the service and then it restarts. Better to have no upgrades than to let this continue.
The cause of this exception was a missing executable when checking
ProjFS.IsGVFSUpgradeSupported(), which seems to call PowerShell. The only reason the stack would have aWin32Exceptionwith "The system cannot find the file specified" is thatpowershell.exeis not on thePATH, which was fixed in #1658.