RandomAccess.Write throws System.IO.IOException: The parameter is incorrect.

[miroslavp]

Description

RandomAccess.Write(SafeFileHandle handle, IReadOnlyList<ReadOnlyMemory<byte>> buffers, long fileOffset) throws IOException on Windows platform when the bytes in the buffers list exceed Int32.MaxValue

Here's the relevant stack trace

System.IO.IOException: The parameter is incorrect.
 at System.IO.RandomAccess.WriteAtOffset(SafeFileHandle handle, ReadOnlySpan`1 buffer, Int64 fileOffset)
 at System.IO.RandomAccess.WriteGatherAtOffset(SafeFileHandle handle, IReadOnlyList`1 buffers, Int64 fileOffset)

I suspect the problem is in the bytesWritten variable, because it is int and it overflows

runtime/src/libraries/System.Private.CoreLib/src/System/IO/RandomAccess.Windows.cs

Lines 435 to 446 in 01aa3d9

	internal static void WriteGatherAtOffset(SafeFileHandle handle, IReadOnlyList<ReadOnlyMemory<byte>> buffers, long fileOffset)
	{
	// WriteFileGather does not support sync handles, so we just call WriteFile in a loop
	int bytesWritten = 0;
	int buffersCount = buffers.Count;
	for (int i = 0; i < buffersCount; i++)
	{
	ReadOnlySpan<byte> span = buffers[i].Span;
	WriteAtOffset(handle, span, fileOffset + bytesWritten);
	bytesWritten += span.Length;
	}
	}

Reproduction Steps

Just call RandomAccess.Write(handle, buffers, 0) on Windows machine where buffers parameter contains multiple ReadOnlyMemory<byte> buffers that collectively are larger than 2GB

Expected behavior

It should save the buffers to the file and not throw IOException

Actual behavior

throws System.IO.IOException: The parameter is incorrect.

Regression?

Haven't tried it on .NET 6

Known Workarounds

I guess you can split the buffers in multiple smaller lists and call the method multiple times

Configuration

Which version of .NET is the code running on?
.NET 7

What OS and version, and what distro if applicable?
Windows 10

What is the architecture (x64, x86, ARM, ARM64)?
x64

Do you know whether it is specific to that configuration?
I believe the problem is in the Windows implementation only

Other information

No response

[dotnet-policy-service]

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

[KalleOlaviNiemitalo]

This is not a regression, because RandomAccess.Write was added in .NET 6.0.0, where it already uses the wrong type in int bytesWritten:

runtime/src/libraries/System.Private.CoreLib/src/System/IO/RandomAccess.Windows.cs

Lines 408 to 419 in 4822e3c

	internal static void WriteGatherAtOffset(SafeFileHandle handle, IReadOnlyList<ReadOnlyMemory<byte>> buffers, long fileOffset)
	{
	// WriteFileGather does not support sync handles, so we just call WriteFile in a loop
	int bytesWritten = 0;
	int buffersCount = buffers.Count;
	for (int i = 0; i < buffersCount; i++)
	{
	ReadOnlySpan<byte> span = buffers[i].Span;
	WriteAtOffset(handle, span, fileOffset + bytesWritten);
	bytesWritten += span.Length;
	}
	}

RandomAccess.Read does not have a similar bug; there, RandomAccess.ReadScatterAtOffset correctly uses long total.

[KalleOlaviNiemitalo]

I think the buggy WriteGatherAtOffset can also silently write to the wrong offset and thus corrupt the file, if the fileOffset parameter is already greater than Int32.MaxValue; then the sum fileOffset + bytesWritten won't be negative and won't cause IOException.

[adamsitnik]

@miroslavp thank you for a detailed bug report. You are right, it's a bug. Since you have found the place that requires the fix, would you like to send a PR with a fix?

[NicoAvanzDev]

I've opened a pull request with the fix for this issue. Let me know if it's ok for you guys. Thanks you all !

[miroslavp]

@miroslavp thank you for a detailed bug report. You are right, it's a bug. Since you have found the place that requires the fix, would you like to send a PR with a fix?

Thank you, but I prefer not to. I don't feel confident enough to do that. If you guys can fix it, that would be awesome.

[NicoAvanzDev]

@miroslavp thank you for a detailed bug report. You are right, it's a bug. Since you have found the place that requires the fix, would you like to send a PR with a fix?

Thank you, but I prefer not to. I don't feel confident enough to do that. If you guys can fix it, that would be awesome.

I've created a PR with the fix and performed testing on it #108380.

Hope this can be appreciated ! Thanks guys for your job !