FileStreamFactoryMock re-opens the path behind a SafeFileHandle instead of adopting the handle

[Mpdreamz]

A real FileStream constructed from a SafeFileHandle adopts the handle: the file is not opened a second time, no new file share is taken, and the stream can therefore never conflict with whatever already holds the file open.

FileStreamFactoryMock instead resolves the handle to a path through ISafeFileHandleStrategy and opens that path again, taking a fresh file share from SafeFileHandleMock.Share. Layering a stream on a handle can consequently fail with a sharing violation where the real file system succeeds.

Reproduction

MockFileSystem fileSystem = new(o => o.SimulatingOperatingSystem(SimulationMode.Windows));
fileSystem.File.WriteAllText("file.txt", "some content");
fileSystem.WithSafeFileHandleStrategy(
    new DefaultSafeFileHandleStrategy(_ => new SafeFileHandleMock("file.txt")));
SafeFileHandle handle = new(new IntPtr(0x1234), ownsHandle: false);

// something else holds the file open exclusively
using FileSystemStream exclusive = fileSystem.File.Open("file.txt",
    FileMode.Open, FileAccess.Read, FileShare.None);

using FileSystemStream adopted = fileSystem.FileStream.New(handle, FileAccess.Read);
// IOException: The process cannot access the file ... because it is being used by another process.

A real FileStream over a real handle succeeds here, because it takes no share.

Expected

IFileStreamFactory.New(SafeFileHandle, ...) — all three overloads — should not take a file share, matching the adoption semantics of the underlying type.

Note on ignoreFileShare

IStorageContainer.RequestAccess already has an ignoreFileShare parameter, but it is a no-op on Windows: FileHandle.GrantAccess only consults it inside if (!_fileSystem.Execute.IsWindows). That may be deliberate, so rather than change its meaning — three call sites in InMemoryStorage rely on it — the attached PR skips taking a share altogether for the adopting case, using the existing FileHandle.Ignore.

Worth deciding separately whether ignoreFileShare being inert on Windows is itself a bug.

[vbreuss]

@Mpdreamz Is this issue still open or was it fixed with #1081 and #1082?

[Mpdreamz]

It's fixed in 7.1.0, but by #1109 rather than #1081/#1082. Those two added OpenHandle itself. #1109 makes a stream on a handle that comes from the ISafeFileHandleStrategy adopt that handle instead of opening the path again, and #1106 does the same for handles the mock creates.

I ran the reproduction above against both versions:

	Windows	Linux
7.0.0	IOException (sharing violation)	IOException (sharing violation)
7.1.0	succeeds, reads the content	succeeds, reads the content

On the side note about ignoreFileShare being inert on Windows: I think that's deliberate after all. Windows does enforce share modes when a file is moved or renamed, which is where InMemoryStorage uses the flag, and the adoption fix no longer depends on it.

So from my side this can be closed. Thanks!