[Bug]: in RC1 copy is failing to overwrite on Linux in some cases that previously succeeded

[danmoseley]

Issue Description

This was on an internal Mariner deployment. The message is access denied eg

...../dotnet/7.0.401/sdk/7.0.401/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Publish.targets(267,5): error MSB3027: Could not copy "obj/Release/net7.0/DOTNET_7_APP.dll" to "/home/site/wwwroot/DOTNET_7_APP.dll". Exceeded retry count of 10. Failed.  [/tmp/8dbb9829ae9e326/DOTNET_7_APP.csproj]

began in 7.0.400 and MSBUILDDISABLEFEATURESFROMVERSION=17.8 is confirmed to make it go away.

Below is @rainersigwald theory

I don't mean to keep the theory a secret. In 17.7, we
changed the MSBuild Copy task
to delete the destination file before overwriting it, because (when it was a link) we would sometimes write
through
the link, corrupting a file in (for example) the NuGet cache. I'm wondering if it's the
delete
that's failing here, when overwriting would be fine. Setting that env var will disable that change (and others, so it's not a go-to-prod solution)

We don't know why the overwrite was working but the delete isn't, and can get traces.

We need to get some fix into RC2. Perhaps reverting the copy task at least for Linux?

Steps to Reproduce

.

Expected Behavior

.

Actual Behavior

.

Analysis

No response

Versions & Configurations

No response

[rainersigwald]

For 8.0.100-RC2, we added an explicit control to opt back into the old behavior MSBUILDCOPYWITHOUTDELETE=1.

Long term I like this proposal from @danmoseley

What about falling back to regular copy if access denied on the delete?

[rainersigwald]

Long term I like this proposal from @danmoseley

What about falling back to regular copy if access denied on the delete?

Well, I liked it. But in fact that's what we're already doing

msbuild/src/Tasks/Copy.cs

Lines 288 to 291 in 3847162

	if (ChangeWaves.AreFeaturesEnabled(ChangeWaves.Wave17_8) && destinationFileState.FileExists && !destinationFileState.IsReadOnly)
	{
	FileUtilities.DeleteNoThrow(destinationFileState.Name);
	}

Where

msbuild/src/Shared/FileUtilities.cs

Lines 857 to 866 in 3847162

	internal static void DeleteNoThrow(string path)
	{
	try
	{
	File.Delete(FixFilePath(path));
	}
	catch (Exception ex) when (ExceptionHandling.IsIoRelatedException(ex))
	{
	}
	}

and

msbuild/src/Shared/ExceptionHandling.cs

Lines 147 to 162 in 3847162

	internal static bool IsIoRelatedException(Exception e)
	{
	// These all derive from IOException
	// DirectoryNotFoundException
	// DriveNotFoundException
	// EndOfStreamException
	// FileLoadException
	// FileNotFoundException
	// PathTooLongException
	// PipeException
	return e is UnauthorizedAccessException
	|| e is NotSupportedException
	|| (e is ArgumentException && !(e is ArgumentNullException))
	|| e is SecurityException
	|| e is IOException;
	}

So unless there's some other exception being fired here (when I try to overwrite a running app on Windows I get UnauthorizedAccessException) something else is going on.

[YuliiaKovalova]

the ticket is blocked by the undergoing release process in the App Services team.
Postponed by December.

[YuliiaKovalova]

The package with patched msbuild was given to app services. We are waiting for extended logs results.

[rokonec]

@YuliiaKovalova Please update status of this issue.

[YuliiaKovalova]

App Service team hasn't gathered logs yet.
Without them we can't proceed.

[YuliiaKovalova]

We have agreed to close it since the requested info wasn't provided and there is a doable way to workaround the issue.
It can be reconsidered after receiving the missed parts.