Ensure FileStream.Position is correct after a failed|cancelled WriteAsync attempt

[adamsitnik]

@stephentoub I've realised that while writes can't be incomplete, they might fail with an exception and in such cases we should update the position as well.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

Issue Details

---

@stephentoub I've realised that while writes can't be incomplete, they might fail with an exception and in such cases we should update the position as well.

Author:	adamsitnik
Assignees:	-
Labels:	area-System.IO
Milestone:	6.0.0

[stephentoub]

I've realised that while writes can't be incomplete, they might fail with an exception and in such cases we should update the position as well.

Just to clarify, this never used to be done in previous .NET releases, either, right?

[adamsitnik]

Just to clarify, this never used to be done in previous .NET releases, either, right?

I think it was since .NET Core 3.1 (as least to some degree):

Details

using System;
using System.IO;
using System.Threading;
using System.Threading.Tasks;

namespace fileCancel
{
    class Program
    {
        static async Task Main()
        {
            const int writeSize = 1024 * 1024 * 1024;
            byte[] buffer = new byte[writeSize];
            using (FileStream fs = new FileStream("test.test", FileMode.CreateNew, FileAccess.Write, FileShare.None, bufferSize: 1, useAsync: true))
            {
                CancellationTokenSource cts = new CancellationTokenSource();
                cts.Cancel(); // cancelled BEOFRE operation started
                Task writeTask = fs.WriteAsync(buffer, 0, buffer.Length, cts.Token);
                await AwaitAndSee(writeTask, fs);

                cts = new CancellationTokenSource();
                writeTask = fs.WriteAsync(buffer, 0, buffer.Length, cts.Token);
                cts.Cancel(); // immediately cancelled AFTER operation started
                await AwaitAndSee(writeTask, fs);

                cts = new CancellationTokenSource(TimeSpan.FromMilliseconds(0.2)); // very short timeout
                writeTask = fs.WriteAsync(buffer, 0, buffer.Length, cts.Token);
                await AwaitAndSee(writeTask, fs);
            }

            File.Delete("test.test");
        }

        private static async Task AwaitAndSee(Task task, FileStream fs)
        {
            try
            {
                await task;

                Console.WriteLine($"Not cancelled, position: {fs.Position}");
            }
            catch (OperationCanceledException)
            {
                Console.WriteLine($"Got cancelled, position: {fs.Position}");
            }
        }
    }
}

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>net6.0;net5.0;netcoreapp3.1;netcoreapp2.1;net48</TargetFrameworks>
  </PropertyGroup>

</Project>

PS C:\Projects\repros\fileCancel> dotnet run -c Release -f net48
Got cancelled, position: 0
Not cancelled, position: 1073741824
Not cancelled, position: 2147483648
PS C:\Projects\repros\fileCancel> dotnet run -c Release -f netcoreapp2.1
Got cancelled, position: 0
Not cancelled, position: 1073741824
Not cancelled, position: 2147483648
PS C:\Projects\repros\fileCancel> dotnet run -c Release -f netcoreapp3.1
Got cancelled, position: 0
Not cancelled, position: 1073741824
Got cancelled, position: 1073741824
PS C:\Projects\repros\fileCancel> dotnet run -c Release -f net5.0
Got cancelled, position: 0
Not cancelled, position: 1073741824
Got cancelled, position: 1073741824

[stephentoub]

I think it was since .NET Core 3.1 (as least to some degree):

Isn't your example only showing it actually happening when the token is canceled in advance, which means the operation never actually starts, with our cancellation prechecks causing the position to not be updated in the first place?

Or, if I'm misunderstanding the example, can you point to what code was updating the position after a failure?

[adamsitnik]

@stephentoub you are right, so far we were not updating the position after failure

FWIW I've checked why in my sample we fail to cancel to WriteFile request. The code calls CancelIoEx using proper arguments:

runtime/src/libraries/System.Private.CoreLib/src/Microsoft/Win32/SafeHandles/SafeFileHandle.OverlappedValueTaskSource.Windows.cs

Line 124 in b3ab2eb

Interop.Kernel32.CancelIoEx(vts._fileHandle, vts._overlapped);

But it fails with ERROR_NOT_FOUND , which we have been always ignoring:

runtime/src/libraries/System.Private.CoreLib/src/System/IO/Strategies/Net5CompatFileStreamStrategy.CompletionSource.Windows.cs

Lines 205 to 206 in 57bfe47

	// ERROR_NOT_FOUND is returned if CancelIoEx cannot find the request to cancel.
	// This probably means that the IO operation has completed.

[adamsitnik]

Closing an re-opening to try to trigger the CI as the last x64 debug Windows build failed with:

Failed to download package 'System.Reflection.Metadata.1.8.0'

full log

[adamsitnik]

@stephentoub could you PTAL?