Re: Beware wildcards in Kill

Tech-Archive recommends: Speed Up your PC by fixing your registry

From: Russ Holsclaw (russ_at_holsclaw.nyet)
Date: 04/08/04 

Date: Thu, 8 Apr 2004 09:10:17 -0600

> It is a long-standing issue that wildcards in a DOS
context (e.g. DIR.EXE)
> do not behave in a reliable manner. For instance '*'
should be 0-or-more
> characters, and '?' should be any single character.
However, if you type the
> following in a DOS command window:
>
> DEL xyz????.dat
>
> then it will delete xyz.dat as well as xyz1234.dat.
>
> You could argue that in this context '?' is handled as
0-or-1 characters,
> but this is out-of-step with the rest of the World
including Windows - just
> try a Search in an Explorer window to see the difference.
>
> However, what is less obvious is that the VB Kill
statement has the same
> totally useless, and very dangerous, semantics.

This behavior is only "illogical" in the context of viewing
the filename as a variable-length character string.

You're overlooking the fact that every file in the Windows
file system has two names: the original DOS-compatible
fixed-length "8.3" name and the variable-length "long" name.
To maintain compatibility between the "old" and "new"
worlds, Windows allows operations against any file by
referencing either name.

The old 8.3 name is stored in the directory in a fixed
11-character data structure, with two separate "fields",
with 8 "filename" characters and 3 "extension" characters.
The period between them is not actually there, and each
portion is stored in a fixed-length field, padded by space
characters [chr$(32), as it were]. The "?" wildcards match
ANY character, including space. The file xyz.dat is stored
in DOS form as XYZ^^^^^DAT (where ^ represents a space, in
this case).

This behavior matches that of the original DOS system, which
was, in turn, designed to match the behavior of the CP/M
file system upon which it was loosely based.

What you're seeing is not truly "illogical" you see, it's
merely the "ghost" of downward compatibility. Like it or
not, that's something that happens to every operating
system, sooner or later.

In light of this, it might have been better if the Windows
file system had allowed a program to specify specifically
whether a filename reference is to the "old-style" name or
the "new-style" one. Unfortunately, as applied to this
particular case, they didn't. On the other hand, it could be
argued that it would have needlessly complicated programming
interfaces, and it usually doesn't create undesirable
results. But... sometimes it does, if you're too fixated
only on the rules of "new-style" filenames, and ignore the
old-style ones lurking in the background.

Relevant Pages

  • A Thank You, And A Couple Of Odd Questions
    ... run in a DOS window under Windows just fine. ... sort of trick that enabled me to insert characters from the ... that I did it inside the quotes of a PRINT command. ...
    (comp.programming)
  • Re: How do you get to the DOS prompt using the Recovery CD
    ... NT has no DOS mode, so you'd have to run that from a DOS mode boot ... Windows writes to the HD. ... then repairing internal file system logic so data can be evacuated. ...
    (microsoft.public.windowsxp.configuration_manage)
  • Re: Handling international characters in filenames on Win32
    ... Some notes, additions and corrections: ... DOS and the Windows actual console ... Not wide characters, just "high ascii" or "accented characters" ...
    (comp.lang.perl.misc)
  • Re: Virus scanning apps that can be started from the DOS prompt?
    ... f-prot for dos which is free but doesn't handle windows pc's properly and fpcmd which isn't free but does handle windows pc's properly... ... f-prot for dos uses dos api's to enumerate the file system and windows support of those api's doesn't provide for complete enumeration of the file system... ...
    (alt.comp.anti-virus)
  • Re: System.IO.PathTooLongException
    ... Note The C Runtime supports path lengths up to 32768 characters in length, ... Windows NT 4.0, Windows 2000, Windows XP Home Edition, Windows XP ... Professional, Windows Server 2003, and Windows Server 2003 NTFS file system ... Unicode APIs. ...
    (microsoft.public.dotnet.languages.vb)