MockFileStream.InternalFlush is not thread-safe

[Arithmomaniac]

System.IO.Abstractions/src/System.IO.Abstractions.TestingHelpers/MockFileStream.cs

Lines 93 to 107 in 05486f7

	private void InternalFlush()
	{
	if (mockFileDataAccessor.FileExists(path))
	{
	var mockFileData = mockFileDataAccessor.GetFile(path);
	/* reset back to the beginning .. */
	var position = Position;
	Seek(0, SeekOrigin.Begin);
	/* .. read everything out */
	var data = new byte[Length];
	Read(data, 0, (int)Length);
	/* restore to original position */
	Seek(position, SeekOrigin.Begin);
	/* .. put it in the mock system */
	mockFileData.Contents = data;

If Thread1 invokes this method, but Thread2 deletes the same file while Thread1 is at line 96, then Thread1 will throw a NullReferenceException at line 107.

I'm not sure what the desired behavior would be, but at a minimum lines 95-97 should be folded into an atomic mockFileDataAccessor.TryGetFile(path, out var mockFileData). I imagine it would look essentially like this, but without the ternary condition:

System.IO.Abstractions/src/System.IO.Abstractions.TestingHelpers/MockFileSystem.cs

Lines 383 to 389 in 05486f7

	private MockFileData GetFileWithoutFixingPath(string path)
	{
	lock (files)
	{
	return files.TryGetValue(path, out var result) ? result.Data : null;
	}
	}

[ymarcov]

Note that mock behavior should be different if it's mocking Unix or Windows filesystems.
On Windows, you can't delete a file that's in use; you should get an IOException in that case.
On Unix, you can delete the file, but as long as the reader's already got a reference to it, the data is still alive until the reader is finished with it.

[fgreinacher]

Thanks for bringing this up @Arithmomaniac!

I think it's a good idea to keep the testing helpers thread-safe where possible.

Happy to iterate on a (draft) PR for this!