[ Back to Table of Contents ] [ << ] [ >> ]


From:    Kan Yabumoto           tech@xxcopy.com
To:      XXCOPY user
Subject: The filename matching schemes in Win32 and DOS
Date:    2009-02-10  (revised with a new subject)

Longname revisited

  When Microsoft introduced the long filename to the Windows operating
  systems (Windows 95, 98, ME, NT4, and 2000), the legacy file access
  method using the shortname alias (the so-called 8.3 format) had to
  be supported.  Having two names for an object solved many problems.
  Yet, it also created a few undesirable side effects, albeit they
  are rather subtle.

  The most notorious aspect of the dual identity for the file and
  directory, is probably the synthesized shortname when a file is
  copied.  XXCOPY's /NX switch (by default) solves most of this
  problems by preserving the shortname.

The filename matching schemes (Loose name-matching)

  A close examination of the behaviors of Microsoft's XCOPY utility
  with regard to the filename matching function reveals an interesting
  but potentially troubling implementation.  That is, the filename
  matching in XCOPY (as well as the DIR command) is performed on both
  the longname and the shortname.  When either of the names matches
  the filename template, the file is selected.

  Say, you have a file \src\longname5.txt (shortname LONGNA~1.TXT).

  When you use Microsoft's file utilities such as the DIR, COPY,
  or XCOPY commands in the Win32 environment, the file can be
  accessed in any of the following commands,

     DIR     \src\*5.txt
     DIR     \src\*1.txt
     COPY    \src\*5.txt
     COPY    \src\*1.txt
     XCOPY   \src\*5.txt
     XCOPY   \src\*1.txt

  So, in the Win32 environment, a filename pattern applies to both
  the longname and the shortname.  Our XXCOPY supported the loose

  Now, try the following commands:

     DIR     c:\windows\system32\*1.dll
     XCOPY   c:\windows\system32\*1.dll    c:\temp1\
     ROBOCPY c:\windows\system32\ *1.dll   c:\temp2\

  You may be surprised that some of the files chosen do not have
  the filename pattern you specified.  A close examination of
  the source directory (try the DIR /X command) reveals that those
  files in question have a SFN like MICROS~1.DLL that matches the

    Our XXCOPY supported the loose name-matching scheme until
    ver 2.97.8.  However, as the number of files in a directory
    has been steadily growing, the chances of encountering an
    inadvertent match to the short (8.3) name has also lately
    become a very serious issue.  With the demise of XCOPY
    (that is no longer supported by Microsoft), it is time for
    us to stop honoring the mindless compatibility in this regard. 
    See below for details.

The /N switch of XCOPY

  Presumably, the idea behind the /N switch of Microsoft's XCOPY
  utility is to emulate the DOS (real mode) environment by handling
  the filename by the shortname (8.3) format.  Indeed, when files
  are copied, the destination will only have the shortnames.
  But, Microsoft programmed XCOPY's filename matching to behave
  identically whether or not you specify the /N switch.

  Let's look at the following lines for the two files listed above.

     XCOPY   \src\*1.txt   /N
     XCOPY   \src\*5.txt   /N

     XXCOPY  \src\*1.txt   /N
     XXCOPY  \src\*5.txt   /N

  In either case, the file, LONGNA~1.TXT will be copied into the

Enter the /NP (Precise name-matching) switch

  As discussed above, a filename pattern is typically matched
  to both the long name and the short name with most of application
  programs in the Windows environment.  This is due to the fact
  that most applications simply use library functions supplied
  by Microsoft.

  Due to the significant increase in the probability of inadvertent
  (and often unnoticed) matches with the short name when the total
  number of files in a given directory becomes very large (say,
  a few thousand files), it became unacceptable for XXCOPY to
  maintain the compatibility in its file-matching behavior to
  Microsoft's products.
  In order to retain a full control of the name matching operation,
  XXCOPY offers you an option on this issue:

    /NP      // Enables Precise Name-matching
    /NP0     // Disables Precise Name-matching

   With versions v2.97.8 or earlier, XXCOPY's default
   name-matching scheme was compatible with Microsoft's
   Loose name-matching scheme (/NP0).

   Starting with v.2.97.8, XXCOPY reversed the default
   and now uses the "Precise name-matching" scheme (/NP)
   by default.

   In practice, you hardly ever need the /NP0 operation.
   After all, Microsoft's Loose name-matching is madness.

The relationship between the /N and /NP switches.

  The /N function forces XXCOPY to view and treat files using
  the short (8.3) names only.  Therefore, even though the /NP
  switch that operates independently with the /N switch, when
  when the /N switch is in effect, the /NP switch setting becomes
  irrelevant.  That's because with /N, the file-selection
  mechanism no longer uses the dual-name matching scheme.

  In short, with /N, the distinction between /NP and /NP0 is moot.

Wildcards: the DOS-way and the Win32-way.

  With the longname in the Win32 environment, came the new filename
  matching algorithm which accommodate the new reality.  But, the
  reality is not very clean when you take a closer look.

     For example,try Microsoft's XCOPY with "very_long_name.html"

     XCOPY  ????????.htm  // 8 characters before the dot
     XCOPY  ????.???      // 3 characters after the dot

     Notice that the filename has 14 and 4 character before and after
     the dot respectively.  But, both of the above command line
     succesuflly matches the file and proceeds.  This is in Win32!!!

     The following command lines using Microsoft's XCOPY behave
     differently depending on the DOS/Win32 environments.

     XCOPY   AB*XYZ.??    // In DOS, ABCDEFGH.OK and ABCDXYZ are copied.
     XCOPY   AB*XYZ.??    // In Win32, neither of them is copied.

     Our XXCOPY/XXCOPY16 faithfully imitates the behavior of XCOPY
     (to do otherwise would make the user even more confused).

     There are many other cases which cause unwelcome surprises...

  We expect many system administrators find themselves in both the
  DOS and Win32 environments from time to time and choose the
  appropriate version (XCOPY16 or XXCOPY) accordingly.  So, having
  two sets of file-matching rules is last thing the users need.
  This is especially true with XXCOPY which now has a lot more cases
  of filename matching situations:  the Wild-Wildcard Source, the
  exclusion specifiers, and the inclusion specifiers (e.g., alternate
  filename templates).

Enter the /NW and /ND switches:

  With XXCOPY, you have full control of the algorithm on filename
  matching with wildcards.

    /NW     Win32-scheme in filename matching (default in XXCOPY)
    /ND     DOS-scheme (the 8.3 filename) in filename matching

      You may combine this switch with other filename-related switches
      (/NP /N /NX).  In most situations, the best choice for XXCOPY
      is /NW/NP/N0/NX (which is the plain defaults).  You may use
      /NW and /N combination which applies the Win-32 wildcard
      matching scheme to the shortname.

      Note the use of /ND (DOS-way) forces the /N switch enabled.

© Copyright 2016 Pixelab All rights reserved.

[ XXCOPY Home ] [ Table of Contents ] [ << ] [ >> ]

Join the XXCOPY group