microsoft.wildcard.matches.txt

`Date: Mon, 14 Jun 1999 09:46:41 +0200  
>From: BROWN Nick <[email protected]>  
Subject: Unwanted wildcard match  
  
I don't normally like to present individual bugs as RISKs, but this one just  
bit me and is so counter-intuitive that I felt I had to report it.  
  
It appears that when Windows NT (and, I imagine, other long-filename-enabled  
Windows variants) matches a user-specified wildcard in a DOS prompt, it  
matches the wildcard against both the full filename, and the pseudo-8.3  
format filename.  
  
For example, in a directory I have two files:  
Shortcut to V1.LNK  
Shortcut to V2.LNK  
  
However, these were created in reverse order, which means that their  
8.3-emulated names were also created in reverse order. So DIR/X shows:  
Shortcut to V1.LNK SHORTC~2.LNK  
Shortcut to V2.LNK SHORTC~1.LNK  
  
Now, I wanted to get rid of "Shortcut to V1.LNK", and a number of related  
files, so I typed  
DEL *1.LNK  
and "Shortcut to V2.LNK" disappeared as well.  
  
The RISK ? With Microsoft, a wildcard can match a filename character that  
you didn't even know was in the filename - indeed, which is part of a  
compatibility system which I don't need to use. (There is no way to predict  
a file's 8.3-emulated name from its full name - another magnificent piece of  
non-design.)  
  
Nick Brown, Strasbourg, France.  
  
e-mail address updates : @coe.int replaces @coe.fr  
for more information, http://dct.coe.int/info/emfci001.htm  
  
  
[RISKS-FORUM Digest 20.44]  
  
-------------------------------------------------------------------------------  
  
Date: Wed, 16 Jun 1999 18:45:08 +0200  
>From: BROWN Nick <[email protected]>  
Subject: More on "Unwanted wildcard match" (RISKS-20.44)  
  
I received quite a lot of mail on this subject. A couple of people  
helpfully tried to explain what they thought was the problem, based on their  
knowledge of DOS, but "assuming" that NT works that way, which it doesn't.  
(RISKs of assuming next-generation systems are infelicity-compatible, I  
guess.)  
  
Yes, in DOS, the wildcards *1.LNK and *.LNK are identical, since DOS treats  
* to mean "everything up to the period" (and there can only be one period).  
However, NT's wildcard matching does more or less what you'd expect - it's  
quite close to, say, how DCL does it under VMS. My problem is that it  
matches both the visible and the invisible filenames.  
  
For example, if I do this:  
  
C:\>copy afile.txt longname2.txt  
C:\>copy afile.txt longname1.txt  
C:\>copy afile.txt longname4.txt  
C:\>copy afile.txt longname3.txt  
C:\>dir /x long*.*  
LONGNA~2.TXT LongName1.txt   
LONGNA~1.TXT LongName2.txt   
LONGNA~4.TXT LongName3.txt   
LONGNA~3.TXT LongName4.txt   
  
> and delete *1.TXT, I "only" lose the first two files.  
>   
Footnote: Microsoft have, however, faithfully re-implemented in NT the  
wonderful DOS bug whereby, if you change a file's extension while copying it  
using a partial-match wildcard, the copy is done as if you said /A for  
ASCII. For example, if I have WINWORD.EXE and I want to copy it to NICK.XXX  
and I'm feeling lazy, I might say  
> COPY W*.EXE NICK.XXX  
without putting the /B switch on the COPY command.  
  
> Try it - you'll get a file truncated to the offset of the first ctrl-Z  
> character in the original.  
  
Thanks also to the person who pointed out that the automatic note appended  
to all outgoing e-mails from our site (saying that our domain name has  
changed), which PGN didn't chop off as he sometimes does with voluble sigs,  
contained a reference to a site which didn't work. Apparently this went  
wrong about two weeks ago. Of the 80000 or so Internet E-mails we have sent  
out since then, nobody else has bothered to mention the problem. This must  
mean something.  
  
Nick Brown, Strasbourg, France http://dct.coe.int/info/emfci001.htm  
  
  
[Risks Digest 20.45]  
  
-------------------------------------------------------------------------------  
  
Date: Wed, 16 Jun 1999 13:40:41 -0500  
>From: "Rumy Driver" <[email protected]>  
Subject: Re: Risks - Depending on a *.xxx convention for file types  
  
This is to note we are still paying for the archaic way of using the *.xxx  
extension for defining the file type.  
  
This is only on Windows platforms which are a legacy of DOS days.  
  
In most other platforms files have 2 parts (e.g. MacOS)  
part1 resource fork  
Contains the actual meta-data - program that created file, date of  
creation, date of last modification ....  
part2 data fork  
Actual data  
  
Now in the DOS-legacy world it is soooo easy to rename a file to another  
extension and the file morphs itself. This is the sneaky trick/way used to  
spread the latest virus/worm.  
  
Another suggestion for *.ZIP files is NOT to double-click them and launch,  
but to use the Classic mode of WinZip and check what is in the ZIP archive  
before extraction. This would have let people know that it's a EXE file and  
they could have taken precautions(?).  
  
Another suggestion is not to have a completely homogeneous environment  
(reminiscent of the potato"e" (apologies to Dan Quayle) famine)  
  
Rumy Driver, Sybase Technical Support  
  
  
[Risks Digest 20.45]  
  
`