You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Inaccurate/Unhelpful MockFileSystem UNC path error message on Unix-like systems #1350
When creating a MockFileSystem with initial files using UNC paths (Windows format) on Unix-like systems, the error handling can be contradictory to the code and inaccurate, as the error message is fixed/hardcoded to Windows paths. For example, when running the below on a Unix-like system
The error reads System.ArgumentException: The UNC path should be of the form \\server\share. (Parameter 'path'), despite the path being in that exact form, and actually requiring the form //server/share on Unix-like systems.
Cause
It seems there is handling of UNC paths with forward-slash separation following this standard in the MockFileSystem class, from this line:
Which will then lead to errors if trying to use backslash-separated UNC paths on Unix-like systems, or presumably forwardslash-separated UNC paths on Windows systems (untested). The error message however, as above, is hardcoded/fixed to the Windows paths:
// In MockFileSystem.csif(lastIndex<0){throwCommonExceptions.InvalidUncPath(nameof(path));}// In CommonExceptions.cspublicstaticArgumentExceptionInvalidUncPath(stringparamName)=>newArgumentException(@"The UNC path should be of the form \\server\share.",paramName);
More than happy to take a look at implementing a solution/fix to this, please go ahead :)
Wondering what the best approach may be. Two potential solutions initially come to mind:
The error message is still fixed, but expand it to mention both platforms, such as: The UNC path should be of the form \\server\share on Windows systems and //server/share on Unix-like systems
The error message is dynamic and will be platform-specific, producing either the current message on Windows systems, or a similar one with the corrected path on Unix-like systems
Would be interested on your take here, or if there is another preferred way to go about this I may be overlooking
Wondering what the best approach may be. Two potential solutions initially come to mind:
The error message is still fixed, but expand it to mention both platforms, such as: The UNC path should be of the form \\server\share on Windows systems and //server/share on Unix-like systems
The error message is dynamic and will be platform-specific, producing either the current message on Windows systems, or a similar one with the corrected path on Unix-like systems
Would be interested on your take here, or if there is another preferred way to go about this I may be overlooking
I would go with your second suggestion. System.IO.Abstractions will always behave as the host operating system, so just having the correct message for the current operating system seems sufficient.
Activity
vbreuss commentedon Oct 9, 2025
Thanks for reporting. Should I assign this issue to you, @HarrisonTCodes?
HarrisonTCodes commentedon Oct 9, 2025
More than happy to take a look at implementing a solution/fix to this, please go ahead :)
Wondering what the best approach may be. Two potential solutions initially come to mind:
The error message is still fixed, but expand it to mention both platforms, such as:
The UNC path should be of the form \\server\share on Windows systems and //server/share on Unix-like systemsThe error message is dynamic and will be platform-specific, producing either the current message on Windows systems, or a similar one with the corrected path on Unix-like systems
Would be interested on your take here, or if there is another preferred way to go about this I may be overlooking
vbreuss commentedon Oct 9, 2025
I would go with your second suggestion. System.IO.Abstractions will always behave as the host operating system, so just having the correct message for the current operating system seems sufficient.
HarrisonTCodes commentedon Oct 9, 2025
Great, thanks - I'll raise a PR with a fix!
github-actions commentedon Nov 22, 2025
This is addressed in release v22.1.0.