Reject wildcards in directory names

[Hans Leidekker]

> 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