> Actually, colon (:) is allowed as part of a Windows file name. This changed at some point (presumably NT). However, almost all Windows tools will be incapable of dealing with a file name that includes a colon, even though the file exists on disk.

I think you are getting confused by stream names. If you try to create a file called "foo1.txt:bar", some Windows tools let you. But that is not an example of a file name containing a colon. The filename is "foo1.txt". In Windows NT (and its successors), a file can be composed of multiple named streams, and ":" separates the file name from the stream name. So "foo1.txt:bar" is actually the the stream named "bar" of the file named "foo1.txt", not a file named "foo1.txt:bar"

Thanks for the clarification.

So let me rephrase. An application can attempt to create a file using the name "foo:bar" and this will result in a new entity in the filesystem that can sometimes be successfully accessed using the name "foo:bar", but generally not.

The core Windows APIs don't have any problem with accessing the file stream "foo:bar". It is just some applications which apply their own file name validation and reject it before passing it to the underlying APIs.

That is seen even in some programs shipped with Windows. For example, cmd.exe. Some of the built-in commands in cmd.exe, for example "del", "type" and "copy", refuse to work with file streams. But that's because cmd.exe's code is detecting the colon and rejecting it as bad filename syntax. If Microsoft would just comment that validation code out, and pass the name including the colon down to the core Windows APIs, those commands would work. But that said, other parts of the cmd.exe code can handle them. The "dir" built-in command even has an option to display file streams, "dir /r". You can also read/write streams using redirection in cmd.exe, e.g. "echo foo > bar:baz" will write the string "foo" to the file stream "bar:baz". And "more < bar:baz" can be used as a workaround for the fact that "type bar:baz" doesn't work. Even though "copy" doesn't understand streams, "copy foo bar" will copy "foo" with its streams intact (assuming both target and destination are on filesystems that support streams), since even though "copy" doesn't understand streams the underlying Windows file copy API it calls does.

Microsoft is unlikely to fix the limitations in cmd.exe since cmd.exe is now considered a legacy component. New features all go in PowerShell. And PowerShell has much better support for streams, it can do everything with them.

So the "generally not" really depends on which applications you are using.