fix: Directory.Move fails on Windows if destination has different case from source

[oni-shiro]

This PR address the issue #1138:

On Windows, MockFileSystem.Directory.Move no longer throws a System.IO.IOException when source and destination path only differ in casing.

[vbreuss]

I don't understand why we would need this, as this method should only be a wrapper around the native Directory.Move. The idea of this library is to not change the behaviour of the underlying file system!

[oni-shiro]

I added this check to handle this issue As it states, the wrapper class and the mock class differ in behaviour.
Another fix would be removing this checks from mock class instead of adding them in wrapper class. Let me know your thoughts.

[vbreuss]

@oni-shiro:
The goal of this library is to provide a wrapper and testing helper that behaves exactly the same as the native file system. The wrapper class should only wrap the native calls so that they can be tested.
When an issue describes a different behaviour between the native file system and the testing helpers, it is always the testing helpers that should be adapted.

I assigned #1138 to you.

[vbreuss]

Could you please add a test (see #1138) to verify the changed behavior?

[oni-shiro]

Could you please add a test (see #1138) to verify the changed behavior?

Sure will do that.

[oni-shiro]

Added the test, removed two outdated tests that does not align with this change. @vbreuss

[vbreuss]

@oni-shiro I fear you misunderstood #1138. It mentions only the case that source and destination differ in casing and only on windows. You should not remove the existing test cases, as they verify the correct behavior in other cases that should not be changed.

[oni-shiro]

Thank you @vbreuss for pointing my mistake 👍. I have made new changes, for this I had to add another StringOperation.Equals method that allows user to pass the String.Comparison behaviour. Currently when initializing the StringOperation we are passing the XFS.IsUnixPlatForm() as a flag to force the checks to be Ordinal or OrdinalIgnoreCase.

Thus I had to add another method that allows user to choose. I have updated the expected test cases alongside that also.

Let me know your thoughts.

[vbreuss]

Let me know your thoughts.

I don't like this additional overload in the StringOperations, just use string.Equals(x, y, StringComparison) where needed (we should avoid bloating the public API surface).

[oni-shiro]

Let me know your thoughts.

I don't like this additional overload in the StringOperations, just use string.Equals(x, y, StringComparison) where needed (we should avoid bloating the public API surface).

I was not keen on using Both StringOperations.Equals, and string.Equals simultaneously to avoid any confusion. But I understand your point, I will revert the change for that.

[oni-shiro]

Reverted the public api related changes on 402f597

[vbreuss]

Thanks, @oni-shiro, I only have some minor suggestions.

[vbreuss]

I adjusted the title and description, as they were no longer up-to-date.

The PR looks good to me. Will release it shortly!

[github-actions]

This is addressed in release v22.0.14.