[API Proposal]: Expose SafeFileHandle.CanSeek

[adamsitnik]

Background and motivation

Recently, we have introduced new RandomAccess type (#24847) which exposes some convenient methods for File IO. To use any of these methods, users need to provide a SafeFileHandle instance which can be obtained by using File.OpenHandle (also a new method introduced in .NET 6).

As of today, all these methods support only seekable files. In contrary to FileStream, SafeFileHandle does not expose CanSeek property, so the users can't easily check whether they can use the new RandomAccess type methods.

API Proposal

namespace Microsoft.Win32.SafeHandles
{
    partial class SafeFileHandle
    {
        public bool CanSeek { get; }
    }
}

API Usage

using SafeFileHandle fileHandle = File.OpenHandle(path, FileMode.Open, FileAccess.Read);
long fileLength = fileHandle.CanSeek ? RandomAccess.GetLength(fileHandle) : -1;

Risks

None. The API has been already implemented for both Windows and Unix and it's being used by FileStream, but it's internal.

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

Issue Details

---

Background and motivation

Recently, we have introduced new RandomAccess type (#24847) which exposes some convenient methods for File IO. To use any of these methods, users need to provide a SafeFileHandle instance which can be obtained by using File.OpenHandle (also a new method introduced in .NET 6).

As of today, all these methods support only seekable files. In contrary to FileStream, SafeFileHandle does not expose CanSeek property, so the users can't easily check whether they can use the new RandomAccess type methods.

API Proposal

namespace Microsoft.Win32.SafeHandles
{
    partial class SafeFileHandle
    {
        public bool CanSeek { get; }
    }
}

API Usage

using SafeFileHandle fileHandle = File.OpenHandle(path, FileMode.Open, FileAccess.Read);
long fileLength = fileHandle.CanSeek ? RandomAccess.GetLength(fileHandle) : -1;

Risks

None. The API has been already implemented for both Windows and Unix and it's being used by FileStream, but it's internal.

Author:	adamsitnik
Assignees:	adamsitnik
Labels:	area-System.IO, untriaged, api-ready-for-review
Milestone:	7.0.0

[stephentoub]

As of today, all these methods support only seekable files.

Assuming in .NET 7 we remove this constraint, and RandomAccess' methods can be used with any SafeFileHandle regardless of whether it's seekable or not (and if not then the offset will just be ignored), is there still utility for exposing this property as well in .NET 7?

[adamsitnik]

is there still utility for exposing this property as well in .NET 7?

I think that we are going to remove the constraint for all Read* and Write* methods, but keep it for GetLength (unless we want to return negative value to indicate that it's non-seekable, but it would be different than FileStream which throws for such files).

Also, there might be some value in terms of validating that given path specified by the user does not point to a regular file.

[terrajobst]

@adamsitnik We took a quick look today. We think it's OK, but it would be good to get your take on our questions/feedback.

• Unless there is a strong reason not to, it seems we'd want all three capability APIs from Stream, assuming the goal is to be determine whether the handle can be used to for a certain scenario
  • It seems there is not a lot of value in exposing CanRead and CanWrite because generally the handle that is acquired is known to be readable/writable, whereas seekability is a function of what the file is backed by (e.g. a pipe)
  • Should this be moved to RandomAccess instead?

namespace Microsoft.Win32.SafeHandles
{
    partial class SafeFileHandle
    {
        public bool CanSeek { get; }
    }
}

[tmds]

the users can't easily check whether they can use the new RandomAccess type methods

Through #59754, we learned that CanSeek does not indicate support for RandomAccess.

#58381 will relax RandomAccess so it becomes usable with non-seekable files.

I think this means the rationale for this API is no longer valid, and that it shouldn't be added.