Reject wildcards in directory names
hans at it.vu.nl
Sun Nov 23 10:06:25 CST 2003
> 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?
More information about the wine-devel