From: Kan Yabumoto tech@xxcopy.com
To: XXCOPY user
Subject: XXCOPY Frequent Asked Questions (FAQ)
Date: 2001-09-01
===============================================================================
Q0: Can I do xxxxxxxxxxx with XXCOPY?
(Fill in xxxxxxxxxxx with your own words)
A0: The most likely answer to the question is YES. XXCOPY can do
most common file management jobs quite nicely. But, as the
number of the XXCOPY switches grows, it is getting harder and
harder to find the right command line argument for a given job.
The recent addition of a few technical bulletins should help.
for Command Line Syntax XXTB #25
for Command Reference Alphabetic Listing XXTB #26
for Command Reference Functional Classification XXTB #27
for The Wild-Wildcard Source Specifier XXTB #28
Especially, the Functional Classification article, XXTB #27
seems to be the easiest way to see the overall picture.
If your company has an urgent need for a file management job whose
requirements are mostly met by XXCOPY but not exactly, and you wish
to have an XXCOPY with a minor customization, please consult us.
We may provide solutions to your need at reasonable time/price.
Q1: What is the difference between XXCOPY, XCOPY, and other similar
programs.
A1: Let us list the utility programs which are related one another.
XXCOPY.EXE The logical extension to XCOPY - most powerful.
XCOPY.EXE Microsoft's command-line based copy utility
COPY Internal command to COMMAND.COM (Microsoft)
XCOPY32.EXE XCOPY's Win-32 program which XCOPY runs when
invoked inside Win9x/ME/NT/2K.
XXCOPY16.EXE XXCOPY's predecessor. written for 16-bit (real mode)
environments such as DOS. Supports most but not
all of XXCOPY's switches.
ROBOCOPY.EXE Microsoft's version of an extended XCOPY utility.
It is bundled in Windows NT/2000/XP Resource Kit.
ROBOCOPY runs on WinNT or Win2000, not DOS nor Win9X.
DCOPY32.EXE Essentially the same as XXCOPY.EXE. It is bundled
with Pixelab's DATMAN-99 tape control software.
DCOPY.EXE Essentially the same as XXCOPY16.EXE. It is bundled
with Pixelab's DATMAN-DOS tape control software.
In short, XXCOPY and XXCOPY16 are Pixelab's products which
extend the features of XCOPY32 and XCOPY respectively.
Q2: I need to copy the top level of a directory structure only.
I want to copy the user home directory structure from one server
to another without copying any sub dirs or files. I have tried
the /T switch but it seems to copy the sub dirs.
A2: Among all switches, the feature to go deep into subdirectories
is controlled by /S (for subdirectory) and /E (for subdirectory-
even-if-it's-empty). Therefore, if you don't use /S or /E in
the switches, it's OK. However, these switches are also
incorporated in a few other combined switches such as /BU
(equivalent to /R/I/BI/Q/C/H/E/V/Y) and /CLONE (equivalent to
/KS/H/E/R/Q/Y/BI/ZY) which makes it tricky.
The easiest way to avoid the inclusion of /S or /E in such hidden
cases is to explicitly cancel such hidden inclusion by adding
/S0 the end of your switches. That is, you can combine with any
switches and put the /S0 switch to the right which will be
evaluated last and therefore override any earlier inclusion.
XXCOPY c:\mysource c:\mydest /CLONE /S0
Q3: I want to clone source to destination but only files with certain
extension(s). When I use XXCOPY c:\src\*.ext d:\dest /CLONE
it also deletes files with different extension at destination.
I cannot figure out which switches to use.
A3: As explained in A2 above, the /CLONE switch is a shortcut for a
combination of switches. In this particular case, the /ZY switch
is responsible for the file deletion. As the name implies,
the CLONE operation is to create a destination directory which
resembles to the source directory as closely as possible. That
includes the removal of extra directory and files that should not
be there. So, to retain all the component switches of /CLONE
except the /ZY part, just add the cancelling switch (/Z0) to the
right hand side. That is /CLONE /Z0 will do the job.
When you glance over the set of switches that are supported by
XXCOPY, you will find a cancelling switch for nearly every switch
(which usually ends with a zero (0) at the end). The cancelling
switches are convenient to reverse the effect of a long combination
of switches which has been set earlier (to the left hand side).
Q4: When I use the Win9x boot diskette, I cannot use XXCOPY since
it is the 16-bit (essentially a DOS) environment. Although I
can use XXCOPY16, it does not use any long filename. How can
I copy directories in DOS (real mode) and restore long names.
A4: It is true that there is no one-step solution to deal with the
long filename. But, this is what we recommend.
1. Copy files using any of the 16-bit utilities you have.
This will give you many files and directories with funny
names (e.g., \PROGRA~1). That is fine as the fist step.
We suggest the use of XXCOPY16, simply because it is the
most versatile utility with lots of options. If you want to
include hidden files and also to preserve file attributes,
we suggest XXCOPY16.
XXCOPY16 c:\mydir d:\mydir /KS /H /E /R
2. Once you are in Win32 (Win9x/ME/NT/2K), run XXCOPY with the
special file renaming switch as follows
XXCOPY c:\mydir d:\mydir /NL /E
In most cases, you probably want to add the /E switch to
handle all files and subdirectories inside.
Q5: When I use the /RS switch to delete a directory, it always shows
a prompt "Dir (Y/N/A/R/S)? How can I get rid of the prompt inside
a batch file. Also, what are the meaning of the prompt?
A5: The Remove switch group has additional level of confirmation
prompt due to the deadly consequences. The prompt is controlled
by the /PD (Prompt-on-Directory) and /PD0 (No Prompt-on-Directory)
switches. It appears before a directory is to be processed.
Rather than having All-or-Nothing control, it provide the R and S
responses which gives you Partial-Yes options.
(Y/N/A/R/S)?
Y for Yes (Yes, process the current directory for removal)
N for No (No, skip the current directory and go to the next one)
A for Yes for All remaining directories (suppresses subsequent prompts)
R for Yes for the current and Remaining siblings and its subdirectories.
S for Yes for the current and its subdirectories.
Q6: I try to run a server backup using XXCOPY's incremental backup
switch (/BI). It works well with local drives. But when I
try /BI from one volume to another, sometimes nearly half of the
files always get copied even though I know most of them have never
been changed since the last backup. Why /BI does not work on
some volume?
A6: Add the /FF (Fuzzy Filetime) switch in such cases. With the
switch, XXCOPY considers two timestamps the same if they are
within a pre-determined number of seconds (/FF is the same
as /FF2 --- for plus/minus 2 seconds). In most cases, the
default setting of plus/minus 2 seconds works well.
Here is why...
The /BI operation compares the file size and time stamp between
the file in the source directory and in the destination. Due to
different file time format used in various file systems, the time
stamp on a file gets truncated, resulting in a different file time
after a copy. When such files are compared against their
counterparts in the source directory, the file times do not match.
This is most commonly experienced when you copy files from an
NTFS volume to FAT (both FAT16 and FAT32) volume. Similarly,
FAT and Unix/Linux file system has file date incompatibilities.
File system Time Resolution (Granularity)
----------------------------------------------
FAT12 2 sec
FAT16 2 sec
FAT32 2 sec
NTFS 100 nsec
Unix/Linux 1 sec
Whenever you run XXCOPY operation which involves a file date
comparison (e.g., /BI, /BX) across different file systems,
use the /FF switch.
Q7: Is there a way to perform an incremental backup but ignore the
file time. That is, I want to select files of different size.
A7: Yes, the /BZ switch is for you. You can choose a backup scheme
from the following variations.
/BI Backs up incrementally, different (by time/size) files only.
/BB Backs up brand new files only (does not overwrite existing ones).
/BN Backs up newer files only (includes brand new files).
/Bo Backs up older files only (includes brand new files).
/BX Backs up different-date files (includes brand new files).
/BZ Backs up different-size files (includes brand new files).
/BS Selects exactly the same files (this is useful with /RS).
/BU Standard Backup switch (same as /r/i/bi/q/c/h/e/v/y)
/U Updates the files that already exist in destination.
Note: The /Bx switches are mutually exclusive one another,
but /U may coexist with a /Bx switch.
Q8: I have seen variations for the home page URL of XXCOPY.
Which is the real home page?
A8: The current official home page URL for XXCOPY is
http://www.xxcopy.com/
Our corporate home page is
http://www.pixelab.com/
Now, all of the freeware download files are stored at the
following directory:
http://www.pixelab.com/download/
In the past, we have also used the following addresses
http://www.xxcopy.com/xxcopy/
http://www.datman.com/xxcopy/
Now, we encourage you to use the shorter form.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
We also run a beta test for which we estabished a full web site:
http://www.xxcopy.com/betatest/
If you are looking for a feature which is not supported by the
current release version, you may try the beta test site. The
documentation files in the batatest site reflect the extended
functionality of the beta version.
Usually, a beta test version is well debugged. But, of course,
it is less mature than the current release version. Since we
pay close attention to bugs and we try to correct serious
problems as soon as they are discovered, you may estimate the
stability of a particular beta test version by the date it was
created. If you feel uneasy to run an "untested" version, wait
a few weeks. If the same beta test version is still there,
it will have gone through the scrutiny that much longer.
Q9: I can't back up the Program File directory using XXCOPY. Why?
A9: It is very likely that you are not using quotation marks around
the source directory name. XXCOPY processes the command line by
splitting the string of command line text into pieces using the
space (or tab) character as the delimiter which separates the
line into components. When you have a multi-word name such as
"Program Files", XXCOPY will see it as two components. You
must tell XXCOPY that the two words are actually just one piece
by surrounding the directory name using the double quotes (").
XXCOPY c:\Progam Files d:\dest\ // WRONG!!!
XXCOPY "C:\Program Files" d:\dest\ // CORRECT
This is not XXCOPY's idiosyncrasies. You can apply this technique
to any operation in a DOS Box. E.g., try it with DIR, CD, etc.
DIR "C:\Program Files"
CD "C:\My Documents\My Pictures"
Q10: I can't make the /Fo, /ON and even /OA to work. Here's my command
line looks like. What is wrong?
XXCOPY c:\mysrc\ c:\mydest\ /s /Fo c:\temp\mybackup.log
A10: This is a quite common problem with first time users. As stated
in the previous answer (A8), the space (and tab) character plays
a very important role in the command line. Although it may seem
hard to read, any parameter for an XXCOPY command switch (such
as /Fo which needs the filename) must follow the command switch
immediately without a space character. So, in your case, type
/Foc:\temp\mybackup.log (without space after /Fo)
Although there are many command-line programs which permit or
even require a space between the command switch and its parameter,
XXCOPY is one of those programs that does not allow a space there.
Actually, allowing an optional space between the command letter(s)
(such as /Fo) and its parameter would create undesirable ambiguity
in the command line syntax, it is best to keep it strict, albeit
a bit ugly to read without a space there.
Q11: My log list which is created by either /ON or /OA does not
include the list of files just copied. How can I list the
files which are successfully copied in the log file?
A11: The /ON/OA output was meant to be for error logging. When
you make a big backup job and save a log file, the few lines
of error will be buried in the huge list of filenames. Therefore,
it is a deliberate XXCOPY design not to dilute the log file
with voluminous success cases. If you want a list of backup log
that contains the names of the files which are copied, use the
/Fo switch which is equivalent to the console output you get
using the /F switch.
Q12: But, /Fo always overwrites the existing list file. Is there
a switch which allows me to append the list to an existing
list file?
A12: No, there is no Append equivalent in the /Fo switch. But, you
can write the following sequence in your batch file to achieve
the same goal.
...
xxcopy \src\ \dst\ /fonew.lst
type new.lst >> grand.lst
...
Q13: When I run a backup using XXCOPY (XXCOPY src dst /CLONE), on
some file, I get a "data mismatch" error message. What does it
mean?
A13: Immediately a file is copied, XXCOPY checks the size of the newly
created file in the destination directory. If the file size does
not match the source, the error message will be shown. Under
normal circumstance, this should not happen. But, in a multi-
tasking environment such as Windows, a file which was just
closed may be subjected to a modification by another process which
is not necessarily a fatal condition. XXCOPY does not interpret
the severity of such an incident. Therefore, it is up to you to
make the assessment as to the purpose of the file. In many cases,
the error condition is not very serious. Otherwise, you may turn
off *ALL* processes except XXCOPY when you clone the current volume
to another volume.
Q14: I want to obtain a list of files using XXCOPY's rich set of file
selection mechanism but without acutally causing any actions like
copying or removing files --- just a listing only. Also, I want
just a bare listing without even the file size info.
A14: XXCOPY is no longer just a file copy utility, but a general purpose
file management tool and searching and making a list of files is one
of the jobs XXCOPY is well equipped. I will show you a few examples
as the answer
XXCOPY c:\mydir\*.jpg /S /L
The searchspec has the base directory part and a template part.
/S is to include subdirectories (which usually the case)
The /L switch is the starting point. It shows file size.
XXCOPY c:\mydir\*.jpg /S /L /ZS
/ZS without the sign-on and statistics info. The bare list.
XXCOPY c:\mydir\*.jpg /S /LL /ZS
/LL gives you longname only
Actually, /Lxxxx is a general purpose list-formatter. You can add
L(ongname), S(hortname), Z(size), D(ate), T(ime), A(ttributes).
Since Longname varies in length, for best list, place L last.
Some more variations:
XXCOPY c:\mydir\*.jpg /S /ZS /LD // D(ate) L(ongname)
XXCOPY c:\mydir\*.jpg /S /ZS /LDZL // D(ate) S(ize) L(ongname)
XXCOPY c:\ /DA#0 /S /ZS /LDZL // Only the files made today
Q15: When I use XXCOPY16 in DOS and duplicate the entire C: drive to D:
using the following command, I get funny filenames in the destination
like XXXXXX~1.XXX.
XXCOPY16 C:\ D:\ /CLONE
How come the files are not copied correctly?
A15: Although XXCOPY16.EXE supports almost all XXCOPY.EXE command switches,
the longname related features (such as the handling of files using
the long filename) cannot be supported. The limitation is not of
the XXCOPY16 program. It is the real mode (DOS) environment which
does not support the long filenames. This is exactly why Microsoft
invented the "alias" 8.3 filename in order for legacy (DOS) programs
to be able to access files created under Win9x and NT/2000/XP with a
long filename. For more information about duplicating a disk drive
under Win9x, there is another article on the subject with great detail
XXTB #10.
Q16: I understand XXCOPY can duplicate the system disk for Win9x/ME.
What about the WinNT or Win2000?
A16: No. Not at this moment. We have not come up with a sure way to
make a bootable WinNT or Win2000 disk using XXCOPY and standard
set of tools. We have been asked by many users why not.
Let me briefly explain what is involved in making a bootable disk.
The initial step in booting a Windows system is to have BIOS access
the Master Boot Record (MBR, the first sector of the first drive),
which determines the partition information and supplies the initial
bootstrap program. This very small program is then copied into the
main memory and the processor will start executing the program.
Normally, the MBR data is initialized by FDISK (or other specialized
toos). XXCOPY does not access the MBR. That is why in the article,
we show you when and how to use FDISK. In the case of WinNT/2000/XP,
the lengthy OS installation procedure writes the MBR with its own
boot program. So, the MBR certainly is one factor.
Secondly, a handful of key files (such as \WinNT\system32\security)
are locked by the system while WinNT/2000/XP is running. Since the
system refuses to share these files with any other application,
XXCOPY can never access these files (about a dozen or so). In the
case of Win9x, most system files in the \Windows directory are
accessible in read mode, and XXCOPY has no problem accessing nearly
all of them from a Win9x session. It is entirely possible that one
can write an elaborate multi-step batch script to access those key
files from DOS. We just have not done our homework on this subject.
Q17: Is there a way to backup a directory and keep the time-stamp of
the source directory (and those of the subdirectories) so that
when I restore the directory later, the time-stamps will exhibit
the original directory-creation time?
A17: If you run XXCOPY under NT/2000/XP, newly created directories in
the destinaion will get the same timestamp. But, under Win9x/ME,
unfortunately no. As far as we know, there is no File I/O API
in the Win9x programming (or in DOS for that matter) which allows
a program (such as XXCOPY) to set or modify the time value for
a directory. We feel it is a serious omission of in the Win32
implementation. The only ways to achieve the objective are to use
some programming tricks. But, possible side effects and risk of
compromising the system integrity is too great. It is a serious
omission in API functionality when Microsoft implemented Win32
for the Win9x/ME environment.
Q18: When I right-click the icon of the XXCOPY.EXE file and examine
the version number, it is different from the one the program
shows at the banner line. Why? And, which one to believe?
A18: We have traditionally used version numbers which consist of
four digits which are grouped in to three parts like 2.60.0.
Unfortunately, the version information which can be attached
to an EXE file (to be viewed in the property sheet of the
EXE file) has a format of four digits which are always split
into four parts of single digit. We don't really like the
format and we can't do anything about it.
Besides, it is somewhat time consuming to set the property sheet
version number every time we build a beta version (which are
often made for tentative debugging purposes). To be honest,
more often than not, we forget spending time in adjusting the
property sheet section while we are concentrating on removing
bugs and making a few experiments to see a particular problem
is gone for a user's environment. The property sheet is just
a distraction as far as we are concerned.
Just disregard the version number property sheet and take
XXCOPY's banner line (which are very prominent) at its face
value.
[ Table of Contents ]
[ << ]
[ Show as Detached ]
[ >> ]
|
On-Line Manual 
XXTB #011