[ 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: 2001-02-14 (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.
Recently, Microsoft added the new /N switch to its XCOPY utility
which handles the filename using the shortname. That is, the
behavior of Microsoft's XCOPY is somewhat like our XXCOPY16
(which can be launched in the Win32 environment).
------------------------------------------------------------------
Microsoft's recent addition of the new /N switch to its XCOPY
forced us to provide the same function in our XXCOPY in order to
maintain full compatibility. The function which was previously
assigned to the /N switch (the shortname preservation) is now
denoted by /NX (and /NX0 to disable).
------------------------------------------------------------------
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. As you might expect, our XXCOPY
also behaves in the same way.
XXCOPY \src\*5.txt
XXCOPY \src\*1.txt
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.
Wait a minute. You asked for \src\*5.txt, and you got LONGA~1.TXT.
We have problem with this behavior. The filename matching scheme
produced this side effect, thanks to the double identity of files
in Win32.
Ideally speaking,
We have to characterize the filename matching scheme implemented
by Microsoft's various file utilities as sloppy at best. And,
our XXCOPY must faithfully reproduce the same sloppiness :-(
Ideally, you should be given an option to exclude either of the
longname or the shortname from the file matching scheme. At least,
the shortname-only copy operation would not bring in files which
does not match in the context.
Enter the /NP (Precise name-matching) switch
XXCOPY allows you to specify a more precise filename matching
operation by the /NP switch. When this (/NP) switch is present,
the filename matching operation will use the more precise filename
matching method by selecting only one name (long or short) to
match the filename. If it is absent (/NP0), then, the filename
matching uses both the longname and shortname to select the file.
that is, there are four possible switch combinations:
Switch combination Long/Short name matching scheme File handling
----------------------------------------------------------------------
/N0 /NP0 (default) both long and short (loose match) longname
/N /NP0 both long and short (loose match) shortname
/N0 /NP only longname (precise match), longname
/N /NP only shortname (precise match), shortname
Note: Since the /N0 switch is default, you may not see it in examples.
Examples of usage
XXCOPY \*~* /S /LSL /NP // list files with the tilde(~)
// character in the longname
XXCOPY \*~* /S /LSL // without /NP, you get a list of
// mostly shortname aliases.
XXCOPY \*1.DOC /S /NP // copy document files with the
// first part ending with "1"
XXCOPY \*1.DOC /S // again, without /NP, the pattern
// is too common in the shortnames
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-Wild-Source, the
exclusion specifiers, and the inclusion specifiers (e.g., alternate
filename templates).
Enter the /NW and /ND switches:
With both XXCOPY and XXCOPY16, you have full control of the
algorithm on filename matching with wildcards.
/NW Win32-scheme in filename matching (default in XXCOPY)
/ND DOS-scheme in filename matching (default in XXCOPY16)
With XXCOPY (Win32 version)
In the case of XXCOPY, 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 just /NP
by relying on the 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.
With XXCPY16 (DOS version)
In the case of XXCOPY16, you don't have other choices in
filename handling. Due to the operation environment, it
the following switches are not supported by XXCOPY16:
/N /N0 // shortname/longname access scheme (always /N)
/NP /NP0 // loose/precise filename matching (always /NP)
/NX /NX0 // does not support longname (always /NX0)
Note that here with XXCOPY16, in the 16-bit DOS environment,
you can use the more advanced (preferred) wildcard treatments
by choosing /NW even though the underlying filename is still
in the short (8.3) format. This is in contract to the fact
the opposite is not true that XXCOPY, the 32-bit version,
cannot select /ND switch for longname (/N0) format.
© Copyright 2008 Pixelab, Inc. All rights reserved.
