[ Back to Table of Contents ]
[ << ]
[ >> ]
XXCOPY TECHNICAL BULLETIN #18
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
pattern.
----------------------------------------------------------------
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
destination.
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 2010 Pixelab, Inc. All rights reserved.
