Hi Bill.

You expect open to identify and reject all invalid names.

What I actually said in my OP was:

[...] before this I trusted the open to tell me if there was a problem with creating an output file.

In this case with a colon in the filename, a file was created successfully and output was correctly written to the Alternate Data Stream as the other monks demonstrated to me. I bet I'm not the only one who had never heard of this newer feature of Windows. I was surprised and curious about this. My current script doesn't really need to completely validate the filenames since the names are not from user inputs. However I have coworkers who sometimes make clumsy changes so I try to make things bulletproof.

Have you seen cases where the open() function did not correctly identify and reject invalid names?

Four of your ten test cases were valid filenames which opened correctly. Five of the six invalid names correctly failed to open. For the sixth invalid name, windows took the strange corrective action you describe as a 'feature'. I do not have a clue what makes this name special. We have no idea how other invalid names may be handled. Code which makes any assumptions about invalid names is simply not 'bullet-proof'. Your simple test probably finds enough errors to be useful. You may even consider it an advantage that it allows some special cases that are not strictly valid.
Bill

The term 'bullet proof' can be relative. Compared to some of my co-workers who write scripts that read, write, copy, and move files blindly to UNC folders and drives that are sometimes full my scripts are very resilient and bullet proof.

Thanks for your help.