Path.GetInvalidPathChars() Does not Return the Same Character Set between .NET4.8 and .NET 6.0.1 on Windows

[kabua]

Description

Path.GetInvalidPathChars() returns a different character set between .NET 4.8 and .NET 6.0-windows.

According to Path.GetInvalidPathChars Method Remarks documentation ...The full set of invalid characters can vary by file system. Okay, but running .NET4.8 vs .NET6.0 on the same machine using the same OS should return the same results since the file system has not changed, correct?

Reproduction Steps

Project file:

  <PropertyGroup>
    <TargetFrameworks>net48;net6.0-windows</TargetFrameworks>
    <LangVersion>latest</LangVersion>
  </PropertyGroup>

Test code:

var frameworkDescription = RuntimeInformation.FrameworkDescription;
var osDescription = RuntimeInformation.OSDescription;
var osArchitecture = RuntimeInformation.OSArchitecture;

var illegalPathChars = "[" + Path.GetInvalidPathChars().Join(null, "") + "]";

Expected behavior

.net 4.8 and .net 6.0 running on Windows should return the same character set.

Actual behavior

Running against .NET4.8 returned:

"[\"<>|\0\u0001\u0002\u0003\u0004\u0005\u0006\a\b\t\n\v\f\r\u000e\u000f\u0010\u0011\u0012\u0013\u0014\u0015\u0016\u0017\u0018\u0019\u001a\u001b\u001c\u001d\u001e\u001f]"

Running against .NET 6.0.1 returned:

"[|\0\u0001\u0002\u0003\u0004\u0005\u0006\a\b\t\n\v\f\r\u000e\u000f\u0010\u0011\u0012\u0013\u0014\u0015\u0016\u0017\u0018\u0019\u001a\u001b\u001c\u001d\u001e\u001f]"

Regression?

Yes.
.NET 6.0.1 is missing the following 3 characters: ", <, and >.

Known Workarounds

No.

Configuration

Used: Microsoft Visual Studio Community 2022 (64-bit) Version 17.0.4
On: Microsoft Windows 10.0.19043, X64

Other information

We have been the process of porting our Framework from .NET 4.8 to .NET 6.0 on Windows and when we ran our unit tests, one of our unit tests failed due to the above issue.

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Path.GetInvalidPathChars() returns a different character set between .NET 4.8 and .NET 6.0-windows.

According to Path.GetInvalidPathChars Method Remarks documentation ...The full set of invalid characters can vary by file system. Okay, but running .NET4.8 vs .NET6.0 on the same machine using the same OS should return the same results since the file system has not changed, correct?

Reproduction Steps

Project file:

  <PropertyGroup>
    <TargetFrameworks>net48;net6.0-windows</TargetFrameworks>
    <LangVersion>latest</LangVersion>
  </PropertyGroup>

Test code:

var frameworkDescription = RuntimeInformation.FrameworkDescription;
var osDescription = RuntimeInformation.OSDescription;
var osArchitecture = RuntimeInformation.OSArchitecture;

var illegalPathChars = "[" + Path.GetInvalidPathChars().Join(null, "") + "]";

Expected behavior

.net 4.8 and .net 6.0 running on Windows should return the same character set.

Actual behavior

Running against .NET4.8 returned:

"[\"<>|\0\u0001\u0002\u0003\u0004\u0005\u0006\a\b\t\n\v\f\r\u000e\u000f\u0010\u0011\u0012\u0013\u0014\u0015\u0016\u0017\u0018\u0019\u001a\u001b\u001c\u001d\u001e\u001f]"

Running against .NET 6.0.1 returned:

"[|\0\u0001\u0002\u0003\u0004\u0005\u0006\a\b\t\n\v\f\r\u000e\u000f\u0010\u0011\u0012\u0013\u0014\u0015\u0016\u0017\u0018\u0019\u001a\u001b\u001c\u001d\u001e\u001f]"

Regression?

Yes.
.NET 6.0.1 is missing the following 3 characters: ", <, and >.

Known Workarounds

No.

Configuration

Microsoft Windows 10.0.19043, X64

Other information

We have been the process of porting our Framework from .NET 4.8 to .NET 6.0 on Windows and when we ran our unit tests, one of our unit tests failed due to the above issue.

Author:	kabua
Assignees:	-
Labels:	area-System.IO, untriaged
Milestone:	-

[danmoseley]

There was some context on this change here: https://github.com/dotnet/corefx/pull/8669/files#r63910570
It seems they are valid in some paths, such as for named pipes. You can use Path.GetInvalidFileNameChars() instead to give you what you expect.

However in general, you should not rely on .NET accurately determining whether a path is well formed, because it depends on the OS and file system. For this reason, we removed many of the checks for a valid path that were done in .NET Framework, allowing the OS to accept or request the path as appropriate. With the benefit of hindsight, GetInvalidXXXChars() has limited value. You might use, Path.GetInvalidXXXChars() as a rough check, for cheaply rejecting paths that are most likely not going to work.

[danmoseley]

Thanks for the report though! Please do reactivate if you still have questions or concerns.

[kabua]

I understand trying to create a cross-platform framework but the key to this bug is the target: i.e. NET6.0-windows. Meaning I'm targeting Windows specifically, therefore, I would expect the return values to honor Windows' invalid characters and not some "most common denominator" set, where now every developer will have to track down and define their own 'invalid characters' - which defeat the whole purpose of even having Path.GetInvalidPathChars(), it would have been better not to have ported this method than to make it worse.

In our case, we are storing path and file information in a database for later processing and we need to know, during the validation phase, if these two fields are valid before adding them to the database.

Proposal
What if there were OS-specific classes for specifying OS-specific values like; invalid path chars, etc? This way developers have the option to either use OS-agnostic or OS-specific information. This also goes for any other path-like (or name-like) objects, since each path-like (or name-like) object can have its own set of invalid characters.

Or, since the Path.GetInvalidPathChars() is a method and not a property, we have the ability to add a default parameter. Like using an OS enum (Any, Current, Window, Linux, iOs, etc), where the default value would be Os.Any.