Yes, because under Unix you can actually create files that contain wildcards, so it should be possible to access them. We just need to prevent the Windows app itself from creating them.
Interesting. What about CopyFile and MoveFile then? CopyFile creates a new file, so following your logic it shouldn't be possible to copy *to* a file with a wildcard name, but it should be be possible to copy *from* a file with wildcards.
What if I want to copy over an *existing* file with wildcards, created under Unix? Isn't that a way of "accessing" the existing file? That's not possible in this scenario since CopyFile is implemented using CreateFile.
And then there's MoveFile, which is implemented using CopyFile and DeleteFile so it's semantics follows from those. So now it's not possible to, say, move existing wildcard files from one directory to another, which is something you want to be able to do isn't it?
Schematically I get this picture:
CreateFile file1 OK CreateFile file2* NOT OK
DeleteFile file1 OK DeleteFile file2* OK
Copyfile file1 file2 OK Copyfile file1* file2 OK Copyfile file1 file2* NOT OK Copyfile file1* file2* NOT OK
Movefile file1 file2 OK Movefile file1* file2 OK Movefile file1 file2* NOT OK Movefile file1* file2* NOT OK
Going about it this way doesn't seem right to me. Shouldn't we simply allow anything the Unix filesystem allows? And thus strip the existing checks for wildcards from CreateFile* and friends? And remove the corresponding test for [Create|Remove]Directory? Would that break any application?
Or simply allow anything Windows allows?
Or should CopyFile and MoveFile perhaps become primitives, so we can have other combinations?
-Hans