From: Kan Yabumoto firstname.lastname@example.org
To: XXCOPY user
Subject: What are the differences between XCOPY and XXCOPY?
Date: 2000-11-30 (revised)
When we designed XXCOPY, one of the key design principles was to
keep the command syntax and the behavior of XXCOPY as close to
those of the original XCOPY program. Although we did not agree
with all the idiosyncrasies of XCOPY, modifying anything XCOPY
already implements would cause substantial confusion to the users.
If we change things arbitrarily, any incremental improvements we
may add would be more than offset by the burden of remembering
the specifics of changes we make. That would not benefit anyone.
Therefore, the changes we added to XXCOPY on purpose are kept to
the absolute minimum. The changes we made are those with
substantial benefits to the users.
The key arguments, source and destination:
Like XCOPY's predecessor, the built-in COPY command of COMMAND.COM,
XXCOPY has two basic arguments without counting any other switches.
XXCOPY source [ destination ]
Here, the semantics of the first argument (source) are almost the
same as the first argument of the traditional XCOPY command. It
is the source file/directory specifier, which is a combination of
the source directory and optional filename pattern specifier.
To be precise, this combination of directory specification with
the filename pattern connected by a backslash does not conform
to a regular so-called pathname specifications. (We will discuss
the exact definition of the source specifier in another Technical
Bulletin article in full detail.) Just remember that the source
specifier is pretty much the same as that of XCOPY.
The destination specifier is optional as in the case of the
original XCOPY and COPY commands. When the destination is not
specified, XXCOPY uses the current directory as the destination
Destination specifier (Difference #1):
In XXCOPY, the destination specifier (when supplied by the user)
refers to the name of a directory whether it exists or to be
created by the command. In any event, the destination never
specifies any particular filename. It always specifies the name
of the destination DIRECTORY.
The reason for this change was the confusing and bothersome
behavior of XCOPY. For one thing, when you specify a non-exist
directory as the destination of XCOPY, you would be greeted by
the familiar prompt:
Does XXXX specify a filename
or directory name on the target
(F = file, D = directory)?
In nearly all cases, you would type D and sigh a long DUHHHHHHH!!!!
Yet, because XCOPY allows the action to include renaming the file
while it is being copied, this ambiguity arises. It is simply
carrying on the legacy of the COPY command. While the copy command's
simplistic "rename-while-you-copy" features using a wildcard
specifier works, we consider the action quite dangerous.
When you use a wildcard with "rename-while-copy" feature which
involves a large number of files, you may accidentally create a
filename collision, which would abort the "rename-while-copy" action
in the middle. The result would be a big mess of partially
We consider the "rename-while-copy" a source of much trouble and
therefore, we discourage your using it. After all, XXCOPY is not
designed to handle one or two files. You can always use the simple
COPY command to do just that. Therefore, in our opinion, eliminating
the double meaning of the destination specifier from XXCOPY's second
argument, we can avoid the side-effects of the "rename-while-copy"
operation altogether and also eliminate the bothersome prompt of
"Do you mean F = File, or D = Directory". Also, we are sure that
everybody has experienced the huge file which is accidentally
created by a simple COPY command with a directory as the source
and a non-existent directory as the destination. The copy command
interprets the destination as a filename rather than a directory and
accumulates all the source files combined into a huge pile of useless
bytes.) Anyway, we had enough confusion with the double meaning
of the destination specifier. XXCOPY dares to correct this problem.
With XXCOPY, the destination is always a directory, never a file.
XXCOPY.EXE (Difference #2):
In the case of XCOPY, it automatically switches between XCOPY.EXE
(a 16-bit program) and XCOPY32.EXE depending on the environment.
In fact it is quite convenient for most users to forget about
the distinction between XCOPY and XCOPY32. Some users may not
even know the existence of XCOPY32.EXE. The actual mechanism is
that when you run XCOPY.EXE in the Win32 environment, XCOPY.EXE
automatically detects the current environment and will execute
XCOPY32.EXE instead. We also consider this feature quite dangerous.
That is because the behaviors of XCOPY and XCOPY32 are not identical.
For example, the treatments of a pathspec with wildcard characters
in the DOS and Win32 environments are significantly different.
Therefore, any large-scale batch file invocation should distinguish
the usage of XCOPY and XCOPY32 to be safe.
The /C switch as the default (Difference #3):
XCOPY32 added the much needed switch, "/C" which allows an
automatic continuation of the copy operations after encountering
an error condition. The C stands for "Continue on error".
Before Microsoft introduced Windows 95, and therefore, the new
XCOPY32.EXE utility, DATMAN-DOS users demanded a solution to
the "share-violation" problem in a backup job of NetWare server.
Even within a modest sized network, there are always a few files
which are open at the time of a server backup job. When XCOPY
tries to open a file which is already opened by another process,
the access results in the error condition where the user had
only three choices: Abort, Retry, or Fail.
None of these choices would let XCOPY continue the operation.
As a matter of fact, XXCOPY's predecessor (DCOPY.EXE) was born
to correct this problem even in the DOS-only days. The first
enhancement to the XCOPY command was the /C switch. Now, with
XCOPY32, which supplies the much-needed switch, the problem was
pretty much behind us.
We had XXCOPY's /C switch work exactly the way XCOPY32's /C
switch works. When it was specified, an error condition that
would have aborted the entire copy operations will continue
until all the qualified files are copied. Alas, the most
frequent technical support issue with the earlier versions
of XXCOPY was due to the omission of the /C switch. After
answering many tech support Emails, we have reached the
conclusion that Microsoft should have made the /C switch its
default mode with a provision to disable it.
For this reason, we broke our rule of adhering to XCOPY32's
behavior exactly, for better or worse. Here, we made XXCOPY's
implementation of the /C switch the exact opposite of how XCOPY32
handles the case. We believe it is in the best interest of the
users. As of this writing, Microsoft's 16-bit counterpart,
XCOPY does not have the /C switch.
With XXCOPY, the /C switch is automatically invoked by default.
You need to specify /C0 to disable this feature and to allow
XXCOPY to terminate at the first instance of an error condition.
The /T switch always enables /E (Difference #4):
Since the /T switch is to construct the directory tree (without
the files), it makes no sense to run it without /S or /E (which
handles subdirectories). We consider the /T/S combination
quite useless and hence chose to always include the E switch
implicitly. We believe the /T switch is now trouble free.
The use of quotatoin marks in a command line (Difference #5):
When a pathname contains an embedded space, the whole string
must be surrounded by a pair of quotation marks (").
Microsoft's XCOPY allows a very liberal usage of quotation
marks to an extent it even accepts bizarre strings. For
example, XCOPY allows the following strings without problem:
"c:\Program Files\My Directory\Myfile.doc" // OK
"c:\Progra""m Files\My Directory\Myfile.doc" // two pairs
c:\Program" Files\My "Directory\myfile.doc // bizarre
We feel XXCOPY should not allow such questionable constructs
even though they are accepted by XCOPY. While it is not
impossible for us to make XXCOPY imitate the behavior closely,
we would have hard time defining and explaining the exact
syntactic rules. So, we chose to deviate from XCOPY's rules.
XXCOPY's rule for the quotation mark is very simple:
The quotation marks must be at the both ends of a pathname.
In almost all other cases, the differences between Microsoft's
XCOPY and our XXCOPY are a result of enhancements rather than
alteration of the XCOPY behavior which already existed.
With the few notable exceptions discussed in this article, the
differences between XCOPY and XXCOPY are remarkably small.
For example, XXCOPY pays attention to the short name alias
which preserves the short name after the copy (TB#02). But,
this is a pure "improvement" rather than "change" which does
not require user attention or precaution.
Therefore, you need not worry much about how to use XXCOPY
if you already know XCOPY. You can pick just a few new
features when you want to learn XXCOPY. Over time, you may
come to like XXCOPY and exploit its unique features to write
your own very powerful batch script for a backup operation.
XXCOPY's major enhancements:
0. Wild-Wild Wild-Wildcard, multi-level, multi-wildcard source
1. /X exclusion specifier and related switches (/EX)
2. /IN inclusion specifier for alternate file pattern template
3. /Bx variations in backup related switches
4. /NX retains the short name exactly
5. /NS /NL renaming short name and long name based on the other
6. /D date matching with many variations
7. /Rx /Z removes files using the versatile file selection schemes
8. /SG/SX gathering files or flattening a directory tree
9. /SZ: select file by the file size (range)
10. /CC /CCY cyclic copy cases handled with the exclusion method.
If you have a suggestion for a new XXCOPY feature, tell us about
it. We will consider any user feedback very seriously.
Please send E-Mail to <email@example.com> for comments, suggestions,
[ Table of Contents ]
[ << ]
[ Show as Detached ]
[ >> ]