Date: Mon, 14 Jun 1999 09:46:41 +0200
>From: BROWN Nick <Nick.BROWN@coe.int>
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 <Nick.BROWN@coe.int>
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" <Rumy.Driver@sybase.com>
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]