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


From:    Kan Yabumoto           tech@xxcopy.com
To:      XXCOPY user
Subject: The leading backslash in a filespec
Date:    2002-01-03 (revised)


  As we see more and more IT professionals who are born after the
  WYSIWYG/GUI scheme was invented, certain key concepts which we
  took for granted are no longer a commonsense...

      xxcopy c:\  d:\  /clone
      xxcopy c:   d:   /clone

  If you know the difference of the two lines, just forget this.
  But, if you consider the two are about the same, this article
  is for you.  The difference is subtle and in many cases, the
  two lines are the same, indeed.  Howerver, in the second line,
  the context determines what will be copied and where will be
  the destination directory (and what will be deleted from the

Absolute pathspec and Relative pathspec.

  The first line of the above example explicitly specifies
  that both the source and the destination are the root
  directory of respective drives.  The second line does not
  specify which directory in the source and which directory
  of the destination within the respective drives.  That is,
  the second example above relies the exact location of both
  the source and the destination directories on the default
  behavior of the OS.  Microsoft's OSes keep track of the current
  (default) directory on each volume.  If it has not been
  defined yet, it will go to the root directory (which is what
  most users want).  Depending on the setting, when you open up
  a DOS box, the current (default) directory may or may not be
  at the root directory.  Also, the current directory of C: may
  be at c:\windows whereas on D:, it may be D:\.  You just
  cannot easily predict what it may be.  Therefore, the common
  assumption that an unspecified path is equivalent to the root
  directory is extremely dangerous with a tool like XXCOPY.
  The consequence of the /ZY switch (which is part of the
  /CLONE switch) on a wrong source or destination could be quite
  FATAL (wipes out all mismatched directories along with their
  entire contents).

Actual examples:

  Let me give you one concrete example.  If you run the
  following command,

      cd  d:\mydir

  The current directory of Volume D: will be set to d:\mydir.
  So, unless you change the current (default) directory of
  Volume D: back to its root, when you say

      xxcopy c:\  d:        /clone

  Then, the line is equivalent to

      xxcopy c:\  d:\mydir  /clone

  Similarly, when volume C:'s current directory is not at the
  root directory (it could be at c:\windows) and you try to copy

      xxcopy c:  d:\          /clone

  In this case, it is equivalent to

      xxcopy c:\Windows  d:\  /clone

  Again, it would give you quite a surprise.

More than one "current" directory:

  With the most popular setting of the DOS prompt which usually
  shows you the "current directory of the current drive" such as
  the following,

    C:\Windows> _

  You don't get any feedback on what is the setting of another
  drive.  For example, the same example shown above, the console
  (the DOS box window)

    C:\Windows> cd d:\mydir
    C:\Windows> _

  When the cd (chdir) command succeeds, there will be no confirming
  message.  The command is quietly accepted and executed.

Why XXCOPY does not supply the leading backslash for you?

  Believe it or not, the way the Absolute pathspec and relative
  pathspec are handled throughout the command line environment,
  be it DOS, Win32, or even Unix, the convention for the absolute
  pathspec and the relative pathspec are so fundamental and
  ubiquitous, if we were to implement XXCOPY's own convention
  and let XXCOPY implicitly supply the missing leading backslash,
  it would create an unbelievable chaos.

  Therefore, XXCOPY cannot help you on this, except it prompts
  you with an additional warning prompt.

Similar cases everywhere:

  The distinction of the absolute and relative path is not limited
  to the source and the destination pathspecs.  It applies to
  any filename you specify in the XXCOPY command line (and also
  for most other programs in Windows).  For example, we often
  hear users complaining about XXCOPY not creating the log file.
  You may have a habit of being casual about creating a log file,

      XXCOPY c:\src\  d:\dst\  /onmyerror.log

  and find no problem.  Yet, when you make a batch file using
  the same line, you may not find the log file as easily.  If you
  don't control the "current directory" of the batch file
  invocation, you may have a hard time locating the log file.

       In Windows (for all the 9x and NT families),
       every shortcut object comes with a setting of
       the "current directory" (Right-click on the icon
       and look for the "Start in" setting).  In a case
       of a program file or a batch file, the directory
       specified in the "Start in" setting becomes the
       current directory when the program is executed.

  My advice is to spell out the full filespec always:

      XXCOPY c:\src\  d:\dst\  /on"C:\My Document\myerror.log"


  So, if you are in a position to advise others on how to use
  XXCOPY with a concrete example, please do not abbreviate the
  leading backslash for cloning a directory.  This one-character
  difference could be just too great to ignore.

  Let me repeat,


      xxcopy c:  d:   /clone     // BAD BAD BAD EXAMPLE!!!

  The /CLONE switch is too dangerous to let the system default
  setting determine the fate.  Instead always specify the
  directory using the full (absolute) directory path

      xxcopy c:\  d:\  /clone

© Copyright 2016 Pixelab All rights reserved.

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

Join the XXCOPY group