Describe the bug
When using FileSystem and MockFileSystem I noticed there is different behavior when creating a new IFileInfo using only whitespaces.
The "error" trails down to the PathVerifier that the MockFileSystem uses
To Reproduce
// Both throw in Linux and windows
var mfs = new MockFileSystem();
mfs.FileInfo.New(" "); // ASCII space
mfs.FileInfo.New("\u00A0"); // Unicode char that's treated as whitespace
// Both pass in Linux
mfs.FileInfo.New("./ ") // Explicit relative path
mfs.FileInfo.New("/ ") // Explicit absolute path
// Passes in Linux
var fs = new FileSystem();
fs.FileInfo.New(" "); // ASCII space
// Passes in Linux and Windows (.NET Core); throws on NET4.8
fs.FileInfo.New("\u00A0"); // Unicode char that's treated as whitespaceExpected behavior
Both calls throw an exception when they should not.
For Linux (whitespace) is a valid file name
For Windows and Linux \u00A0 is a valid file name. However under .NET Framework it also fails
Additional context
In PathInternal.OS.cs .NET has a bool IsEffectivelyEmpty(string? path) method which behaves differently to linux and windows, just to cover those cases.
Currently PathVerifier uses the string.Trim() method, which causes the two explained scenarios
- valid unicode chars get trimmed (
\u00A0)
- a whitespace-only relative path is considered to be illegal when it actually is not under linux.
Describe the bug
When using
FileSystemandMockFileSystemI noticed there is different behavior when creating a newIFileInfousing only whitespaces.The "error" trails down to the PathVerifier that the
MockFileSystemusesTo Reproduce
Expected behavior
Both calls throw an exception when they should not.
For Linux
For Windows and Linux
\u00A0is a valid file name. However under .NET Framework it also failsAdditional context
In
PathInternal.OS.cs.NET has abool IsEffectivelyEmpty(string? path)method which behaves differently to linux and windows, just to cover those cases.Currently
PathVerifieruses thestring.Trim()method, which causes the two explained scenarios\u00A0)