fix: adopt the handle in IFileStreamFactory.New(SafeFileHandle, ...)

[Mpdreamz]

Fixes #1086.

A real FileStream built from a SafeFileHandle adopts it — the file is not opened again and no new file share is taken — so it can never conflict with whatever already holds the file open. FileStreamFactoryMock resolved the handle to a path and opened that path again with a fresh share, so the mock could throw a sharing violation where the real file system succeeds.

All three handle overloads now go through one helper that opens without taking a share, using the existing FileHandle.Ignore.

I did not use ignoreFileShare for this, although it looks like the obvious lever. It is inert on Windows — FileHandle.GrantAccess only consults it inside if (!_fileSystem.Execute.IsWindows) — and three call sites in InMemoryStorage depend on its current meaning, so widening it seemed like your call rather than a side effect of this fix. Whether that is itself a bug is noted in #1086.

Tests cover all three overloads against a file already held exclusively, plus that isAsync: true really does produce an asynchronous stream. They simulate Windows, since that is where the file share is enforced, so they are behind CAN_SIMULATE_OTHER_OS.

Independent of #1081, #1082 and #1083 — this branches from main. I ran into the divergence there and raised it separately per your note.

Run in Release, which is what puts the real file system into the test matrix: Testably.Abstractions.Tests 12075 on net8.0 and 12584 on net10.0, and Testing.Tests 1313 including the five new ones. All pass.

Happy to rework it however you prefer.

🤖 Generated with Claude Code

[Copilot]

Copilot review overview

🟡 Changes recommended

Adopted handles need a non-mutating mode to avoid create/truncate behavior, with coverage for those modes.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1

Open (1)

• Avoid mutating file modes when wrapping an existing SafeFileHandle · New

What changed in this PR

Updates FileStreamFactoryMock to adopt SafeFileHandle instances without acquiring a second file share.

Changes:

• Centralizes handle overloads through one helper.
• Adds adopted-handle behavior bypassing new share registration.
• Adds Windows-simulation tests for sharing and async behavior.

File	Summary
Tests/​Testably.Abstractions.Testing.Tests/​FileSystem/​FileStreamFactoryMockTests.AdoptHandle.cs	Tests handle adoption across overloads, sharing, and async behavior.
Source/​Testably.Abstractions.Testing/​FileSystem/​FileStreamMock.cs	Supports streams that do not acquire a new share.
Source/​Testably.Abstractions.Testing/​FileSystem/​FileStreamFactoryMock.cs	Centralizes handle-based stream creation.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Mpdreamz]

Trimmed the comments here after your note on #1091: the same explanation appeared twice, once as <remarks> on the private helper and once inline. The helper keeps none and one short line remains where the decision is made — why a stream built on a handle takes no share of its own.

No behaviour change; CI was green before and the diff is comment-only.

[Mpdreamz]

No code change — correcting the verification note in the description.

It quoted Debug numbers, and Debug leaves the real file system out of the test matrix: FileSystemTestsAttribute only adds it in Release. Re-run in Release: Testably.Abstractions.Tests 12075 on net8.0 and 12584 on net10.0, Testing.Tests 1313 including the five new ones, all passing. It also drops the mention of two macOS access-time failures I had been describing as pre-existing; they are a Debug-only artefact and do not occur in Release.

[Mpdreamz]

Closing this, since it is covered by what shipped in 7.1.0:

• fix: let a stream on a foreign SafeFileHandle adopt the handle and drop stale SafeFileHandle test exclusions #1109: a stream on a foreign handle adopts it and takes no share of its own (the original point of this PR, FileStreamFactoryMock re-opens the path behind a SafeFileHandle instead of adopting the handle #1086).
• fix: stop FileStream.New(handle) from re-applying the handle's FileMode #1098: FileStream.New(handle) no longer re-applies the handle's FileMode (the Copilot finding here).
• fix: address review findings for OpenHandle and IRandomAccess mocks #1106: the stream wraps the file the handle holds open instead of reopening the path, and disposing it closes a handle the mock created, as FileStream does.

Thanks, @vbreuss.