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


From:    Kan Yabumoto           tech@xxcopy.com
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
  renamed files.

  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.

Other differences:

  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 <tech@xxcopy.com> for comments, suggestions,
  questions, etc.

© Copyright 2016 Pixelab All rights reserved.

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

Join the XXCOPY group