fix: file stream sharing

[HarrisonTCodes]

Closes #1356

This PR adds stateful handling of file streams opened with the FileShare.None option. If a file stream is attempted to be opened whilst another file stream of the same file path and FileShare.None is in use (that is to say, has been opened and not yet disposed), an IOException will be thrown and the creation of the second file stream will be disallowed.

[HarrisonTCodes]

Struggling to initially parse these API tests, not least because I can't seem to reproduce exactly on my machine. However, I expect the cause of failure might be because of the addition of the share argument in the MockFileStream constructor in MockFileStream.cs.

If this is the case, presumably this could be fixed by having share be the final argument (and keeping its default value), so the old argument order, including omission of this new one, would still be valid? This may not be ideal or align with the real file stream implementation though?

Worth nothing none of the factory methods have had their arguments or argument order changed.

[vbreuss]

Struggling to initially parse these API tests, not least because I can't seem to reproduce exactly on my machine. However, I expect the cause of failure might be because of the addition of the share argument in the MockFileStream constructor in MockFileStream.cs.

If this is the case, presumably this could be fixed by having share be the final argument (and keeping its default value), so the old argument order, including omission of this new one, would still be valid? This may not be ideal or align with the real file stream implementation though?

Worth nothing none of the factory methods have had their arguments or argument order changed.

@HarrisonTCodes : You change the public API surface in this PR. The API tests fail, because you didn't make this explicit in the PR. In order for the tests to succeed, you have to run the TestableIO.System.IO.Abstractions.Api.Tests.ApiAcceptance.AcceptApiChanges test once. This will adapt the API files and you have to commit them as part of this PR:

This way accidental API changes can be detected in the review.

Note, that this test is explicit!

[vbreuss]

Can you please add test cases to verify the correct behavior?

[HarrisonTCodes]

Ah, thanks @vbreuss, sorry I missed that. I will try to run these explicit tests locally!

Yes, if we are happy with the structure and changes made in this PR (which seems to be the case based on this request), I shall consider them accepted and add test cases :)

[hangy]

I like the idea!

It might be useful to check if symbolic links need additional handling

[HarrisonTCodes]

I like the idea!

It might be useful to check if symbolic links need additional handling

@hangy thanks for raising this :)

Maybe this is worth more discussion, and a clarification of the scope of this PR. Currently it just targets the behavior shown in the original (linked) issue, ie creation of a MockFileStream with an explicit FileShare.None argument. This seems like handy behavior to have when explicitly passing this argument.

However, there might be appetite to improve the handling of FileShare behavior across more of the APIs, such as in MockFile.cs and implicit file-sharing that mimics the real filesystem with methods like FileInfo.OpenWrite() too.

More realistic handling of other FileShare members might also be worth thinking about in the future too for example. This PR currently just handles FileShare.None. But maybe there is scope to handle these other modes better, such as disallowing write operations on a file when a file stream is open with just FileShare.Read (which could be doable with the use of a ConcurrentDictionary now instead of the old HashSet, with the value representing the share type!)

[vbreuss]

I really like this change. I would just make some things internal to enable future refactorings without breaking changes...

[vbreuss]

I really like the change with the FileHandles class. It looks now way cleaner and is more extensible! I have just one small issue with a method name...

[vbreuss]

When I read the method signature with Try-prefix, I expect it to return a bool. Therefore I would rename this to just AddHandle.

[HarrisonTCodes]

Ah yes, apologies! I have renamed the method to AddHandle in 15ed8d6