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

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


XXCOPY
Version
3.33.3


Released
2016-10-28
©2016 Copyright
Pixelab

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

    XXCOPY TECHNICAL BULLETIN #002

    From:    Kan Yabumoto           tech@xxcopy.com
    To:      XXCOPY user
    Subject: What are the differences between XCOPY and XXCOPY?
    Date:    2000-11-30 (revised)
    ===============================================================================
    
    Introduction:
    
      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
      direction.
    
    
    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.
    
    
    
    
    [ Table of Contents ] [ Show as Detached ] [ >> ]