Jump back to the top page Jump back to the top page

 What is XXCOPY ?
 F A Q 
 About Us (Pixelab) 
On-Line Manual 
XXTB #001 
XXTB #002 
XXTB #003 
XXTB #004 
XXTB #005 
             . . .  


©2016 Copyright

 All rights reserved  
    [ Table of Contents ] [ Show as Detached ] [ >> ]


    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.
    [ Table of Contents ] [ Show as Detached ] [ >> ]