File.OpenHandle() limitations

[iSazonov]

We started to replace custom CreateFileW pinvokes with File.OpenHandle() in PowerShell repository and was blocked because of the API limitations.
Currently there are strong argument validations:

runtime/src/libraries/System.Private.CoreLib/src/System/IO/Strategies/FileStreamHelpers.cs

Lines 62 to 73 in 1a37caf

	if (mode < FileMode.CreateNew || mode > FileMode.Append)
	{
	badArg = nameof(mode);
	}
	else if (access < FileAccess.Read || access > FileAccess.ReadWrite)
	{
	badArg = nameof(access);
	}
	else if (tempshare < FileShare.None || tempshare > (FileShare.ReadWrite | FileShare.Delete))
	{
	badArg = nameof(share);
	}

CreateFileW allows to use many flags for these parameters. Now they are blocked. In particular, we would like to have FILE_FLAG_POSIX_SEMANTICS, FILE_FLAG_OPEN_REPARSE_POINT, FILE_FLAG_BACKUP_SEMANTICS, FileAccess = 0 and so on.

What is the preferred way to solve this problem without using custom pinvoke?

Is it possible to remove these hard checks from the API so that we can use any flags with a simple cast?

The same question for another APIs like File.SetAttributes().

/cc @adamsitnik

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

Issue Details

---

We started to replace custom CreateFileW pinvokes with File.OpenHandle() in PowerShell repository and was blocked because of the API limitations.
Currently there are strong argument validations:

runtime/src/libraries/System.Private.CoreLib/src/System/IO/Strategies/FileStreamHelpers.cs

Lines 62 to 73 in 1a37caf

	if (mode < FileMode.CreateNew || mode > FileMode.Append)
	{
	badArg = nameof(mode);
	}
	else if (access < FileAccess.Read || access > FileAccess.ReadWrite)
	{
	badArg = nameof(access);
	}
	else if (tempshare < FileShare.None || tempshare > (FileShare.ReadWrite | FileShare.Delete))
	{
	badArg = nameof(share);
	}

CreateFileW allows to use many flags for these parameters. Now they are blocked. In particular, we would like to have FILE_FLAG_POSIX_SEMANTICS, FILE_FLAG_OPEN_REPARSE_POINT, FILE_FLAG_BACKUP_SEMANTICS, FileAccess = 0 and so on.

What is the preferred way to solve this problem without using custom pinvoke?

Is it possible to remove these hard checks from the API so that we can use any flags with a simple cast?

/cc @adamsitnik

Author:	iSazonov
Assignees:	-
Labels:	area-System.IO
Milestone:	-

[jkotas]

If you would like to have a full access to all Windows-specific OS flags, I think it is best to use PInvoke.

[stephentoub]

I agree with Jan. The goal of these APIs isn't to expose every option available on every underlying operating system. When you reach the far corners of their tuning and knobs, it's best just to call them directly.

[iSazonov]

No doubt we will.
I would like to understand the meaning of this restriction. This API is already quite low-level in nature, and these parameters already have strict types, which excludes random errors. So it's unclear why we need to block values that could have been passed with cast.

[jkotas]

This is platform-neutral API. What would be do about the undefined flags on Linux if we were to allow them on Windows? How would we warn that the code is non-portable?

[iSazonov]

This is platform-neutral API.

If I asked to add Windows specific values for example in FileAcces enum, it would violate this principle.
This can be compared to the Unsafe.* API. It's not for regular code, but it exists for low-level code nonetheless.
The API in the issue question uses handle. This is a low-level API and the hard constraints in it look unexpected.
And the area in the issue question is pinvokes - it is non-portable area.

(I'm not pushing for the change, but I want to better understand the .Net team's position to avoid fruitless discussions in the future.)

[stephentoub]

And the area in the issue question is pinvokes - it is non-portable area.

But this API is portable. I believe you're asking to remove the validation and allow such bit patterns through. But if that bit pattern doesn't throw when used on Windows, what does it do on Unix? What if those same bits when cast to the underlying APIs on Linux mean something entirely different? What if we want to expose additional options in the future that use those same bit patterns? Etc.

[iSazonov]

I believe you're asking to remove the validation and allow such bit patterns through.

Yes. And the parameters are of a strict type. If a developer makes an explicit cast, it cannot be an accidental mistake, but an intentional action. And it only makes sense for a low-level pinvoke which is not portable.

[stephentoub]

And the parameters are of a strict type

Which is only meaningful if you validate it. But if we allow (FileOptions)12345 through, then that becomes part of the API contract, everywhere.

[iSazonov]

And how is such the cast ((FileOptions)12345) more dangerous than any other? It must be very dangerous indeed if you forbid it, but not the other castes.

[stephentoub]

I don't know what other casts you're talking about. But yes, it's dangerous to allow unvalidated input to be passed through portable APIs.

[iSazonov]

Thanks all for comments!
I will doom and gloom to keep making pinvokes. 😃