[API Proposal]: File.WriteAll bad path names.

[MiLO83]

Background and motivation

Title: File.WriteAllText / File.WriteAllBytes accept unsupported path characters in filename input
Body:
Hi .NET Team,
I've encountered a behavior in both File.WriteAllText and File.WriteAllBytes where they accept strings for the path parameter that contain characters not supported in directory structures (e.g., :, *, ?, <, >). While the underlying system eventually throws an exception due to invalid paths, the initial method call does not validate or proactively reject these characters—potentially leading to confusing errors downstream or platform-specific behavior.
Example:
File.WriteAllText("invalid:filename.txt", "test content");
// No validation at this point – OS handles error during file operation.

Expected Behavior:
These APIs should:

• Either validate the provided filename string for unsupported characters and throw a meaningful exception early, or
• Document clearly that the path string is not validated and platform constraints apply.
  This small change in behavior or documentation could greatly improve developer clarity and prevent runtime surprises—especially in cross-platform or automation-heavy workflows.
  Thanks for all your work maintaining such a powerful platform.
  Best,
  Myles Cameron Johnston

Let me know if you’d like to include platform info or suggest an implementation detail—I’m happy to refine it with you.

API Proposal

namespace System.Collections.Generic;

public class MyFancyCollection<T> : IEnumerable<T>
{
    public void Fancy(T item);
}

API Usage

// Fancy the value
var c = new MyFancyCollection<int>();
c.Fancy(42);

// Getting the values out
foreach (var v in c)
    Console.WriteLine(v);

Alternative Designs

No response

Risks

No response

[dotnet-policy-service]

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

[elgonzo]

"invalid:filename.txt" is not necessarily an invalid file name/path. The validity of file names/paths depends on the targetted file system. Because of this, .NET cannot preemptively decide whether a file name/path is valid but has to pass it to the OS (and the respective filesystem driver).

For example, for NTFS "invalid:filename.txt" is a valid file path. NTFS supports multiple streams per file -- the primary data stream is unnamed, and any other (secondary) data stream is named. Anything behind the first colon : in a file name (a colon that is not part of the drive label) is the name of the stream with an optional stream type.

See:

• https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c54dec26-1551-4d3a-a0ea-4fa40f848eb3
• https://learn.microsoft.com/en-us/windows/win32/fileio/file-streams

Therefore, on an NTFS volume, "invalid:filename.txt" denotes the secondary stream named "filename.txt" of the file named "invalid". After doing File.WriteAllText("invalid:filename.txt", "test content");, you should find a file "invalid" in the current directory if the current directory is on an NTFS volume. If you open it again using the same file+stream name "invalid:filename.txt", you will be able to read the content of the "filename.txt" stream of the "invalid" file. You can also see this secondary data stream by doing dir /r in the directory with the "invalid" file (it should appear as "invalid:filename.txt:$DATA").

(Side note: The size of the file shown by Windows UI is typically showing the size of the primary data stream. Hence, the "invalid" file on the NTFS volume should appear to have a size of 0 in Explorer, despite it actually having a secondary data stream with stuff in it...)

[MiLO83]

what about naming it ":sierra.txt"?

[MiLO83]

https://1drv.ms/u/s!ApkNSGMibQ3ShpdmpdvADOzAz9bdoA?e=pHsJXo

[elgonzo]

what about naming it ":sierra.txt"?

Windows accepts even such a file name, if it is part of an absolute path referencing it as a file in the root directory like "X:\:sierra.txt". It's Windows. It's not .NET's fault nor responsibility what Windows and its NTFS driver does. Yes, Windows and NTFS accepting "X:\:sierra.txt" is silly and nonsensical, but again, that's an issue for Windows, not .NET. Because .NET calls into WINAPI functions, and if the WINAPI is okay with "X:\:sierra.txt", then it's also fine with .NET...

You can write your data like File.WriteAllText("X:\\:sierra.txt", "test content") and then you would be able to read the data back again with File.ReadAllText("X:\\:sierra.txt"). You can do the same with WINAP functions without using .NET. This is an issue/behavior of the OS and its file system stack, not a .NET issue.

[elgonzo]

By the way, you can do silly things like these in the Windows terminal (i am using cmd.exe):

X:\>echo Hello world! >:sierra.txt

X:\>set /p foo= <:sierra.txt

X:\>echo %foo%
Hello world!

Again, that's Windows as it breathes and lives. Not a .NET issue. If this bothers you, you might want to let the Windows team know by using Windows' own "Feedback Hub" app (https://support.microsoft.com/en-us/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332).

[MiLO83]

Do I have to?? Sorry about the Emperors new clothes thing, that's what I'm known for.

[elgonzo]

Do I have to??

Are you referring to my last comment re the Microsoft Feedback Hub app?

[MiLO83]

Dr.Bill Gates, please give MiLO a robot body, a simple "cut" and "paste" should do.
Yours truely,
-

[MiLO83]

https://1drv.ms/u/s!ApkNSGMibQ3ShpdnkcGIrMm5rXxm9g?e=0LDUH8

[MiLO83]

https://1drv.ms/u/s!ApkNSGMibQ3ShpdoAWQgfPGZ_9YTaw?e=UDw1hJ