Date: Mon, 14 Jun 1999 09:46:41 +0200 >From: BROWN Nick 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 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" 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]