Add retry when Directory.Move

[wli3]

Link to GitHub issue for open source changes

https://github.com/dotnet/cli/issues/9289

Link to GitHub dotnet:release/[version] pull request (see Git Prepping a PR from the Release Branch)

#9313

ProjectK TFS bug and changeset for closed source changes (security fix, package authoring, etc)

N/A

Describe the issue and how it manifests to the customer.

When running uninstall and then install on Windows. Due to global tools use Directory.Move underneath, there is a chance the indexer or the antivirus collided (had a handle still open on the prior name). And the installation/uninstalling will fail with access denied error.

What is the impact on the customer?

This impact the producers most. During producer’s test, it is likely they will uninstall and install their tools several times. And the frequency of seeing this error varies machine by machine.

Are there changes that cannot be made in GitHub? (security fixes, etc)

No

Characterize potential risks introduced by the fix.

Low risk. Try action on failure. And Directory.Move, File.Move is atomic. Once it fails it can be retired.

Does the change alter existing behaviors? (return values or types, error messages or exceptions, etc. In
other words, is this a build-to-build breaking change?)

No

What changed?
What will teams need to do to respond?
Once check-in is approved send breaking change mail to netcorebreak

Code reviewers:

What testing has been completed?

manual test

Which platforms are impacted? (Linux | Mac | Windows)

Windows

Effected binaries and packages (exact name)

dotnet.dll, Microsoft.DotNet.Cli.Utils.dll

---

Why check 0x80070005 on IOException
This error is the exact error thrown. It is just an IOException. The only way to detect that is by HResult.

Why don’t use the function above -- RetryOnFileAccessFailure?
RetryOnFileAccessFailure is async. And also in this case, it is awaiting a void. There is some gotcha around it. Since it is so close to release, I choose the safer way. And RetryOnFileAccessFailure ‘s exception is not specific. UnauthorizedAccessException is likely a real error for user to handle for –-tool-path.

Tested with 100 times tight loop. No error

[wli3]

fix https://github.com/dotnet/cli/issues/9289

[wli3]

The following can repo the root cause

using System;
using System.IO;
using System.Threading;
 
namespace console1
{
    class Program
    {
        static void Main(string[] args)
        {
            for (int i = 1; i < 1000000; i++)
            {
                Console.WriteLine(i);
                Directory.Move(@"C:\work\test1\folder", @"C:\work\test2\folder");
                Directory.Move(@"C:\work\test2\folder", @"C:\work\test1\folder");
            }
        }
    }
}
 

result

 …..
….
 
5873
5874
5875
5876
dotnet : 
At line:1 char:1
+ dotnet run >> result.txt 2>&1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError
 
Unhandled Exception:
 
System.IO.IOException: Access to the path 'C:\work\test1\folder' is denied.
   at System.IO.FileSystem.MoveDirectory(String sourceFullPath, String destFullPath)
   at System.IO.Directory.Move(String sourceDirName, String destDirName)
   at console1.Program.Main(String[] args) in C:\Users\wul\Documents\console1\Program.cs:line 14
 

[wli3]

We decide to not fix in 2.1.300 and set it to known issue. Re targeting to 2.1.4xx

[wli3]

@livarcocc need your approval for check in 2.1.4xx