From: Kan Yabumoto firstname.lastname@example.org
To: XXCOPY user
Subject: XXCOPY in a network environment
While XXCOPY is useful in a stand-alone PC, it is widely used in
network environments. Since the default settings of various XXCOPY
operations are designed primarily for copying local drives, you
need to pay special attentions when you operate XXCOPY in a
In this article, the following XXCOPY command switches are examined
specifically with networked environments in mind.
/NX0 Disables the shortname preservation feature
/FF Tolerates up to 2-second difference in time comparison
/CK0 Disables pre-checking of the remaining space
/FU Selects universal time (UNC) for file time
1. The Shortname preservation.
One of the reasons XXCOPY enjoys its popularity among freeware
users is the shortname preservation feature. While this
feature is essential to ensure a proper duplication of the
system drive, the feature may not work (and even becomes a
detriment) in some networked environment with mixed Operating
Systems (or file systems) where the source and the destination
volumes are of different type in file system. It is best if
you test whether the shortname-preserving feature is working
for you on your particular environment.
Since shortname preservation feature requires XXCOPY to
issue a sequence of system calls for renaming, it is a
time consuming operation especially when it fails. If your
XXCOPY exhibits an inordinately low performance, you should
suspect this feature as the likely cause of the trouble.
In that case, just add /NX0 to disable the feature (giving
up the idea of preserving the shortname). For example,
it would be futile for XXCOPY to save the shortname while
the underlying OS (e.g, Linux) does not even support it.
XXCOPY sets the /NX switch on a local drive copy. And, if
either the source or the destination is specified by an UNC
(starting with two backslashes. E.g, \\myserver\cdrive\),
the /NX0 is used as the default setting. If you assert your
desire by an explicit /NX switch, the switch will be honored.
Unfortunately, it is not always easy for XXCOPY to determine
whether the combination of the source and the destination is
suitable for the /NX operation, an explicit command switch
of /NX and /NX0 should work the best.
Starting with v2.43.x, the shortname preservation feature
is disabled by an UNC specifier either on src or dst.
Due to Microsoft' XCOPY added their /N switch in recent
Windows 9x release, XXCOPY's shortname preservation
feature is no longer assigned to /N. Starting with
v2.42.0, it is controlled by /NX and /NX0. We regret
that this change forced us to broke existing batch files.
See article: XXTB #03, for related topics.
2. Time stamp granularity.
Different file systems use different ways to keep track of
the date and time information associated with a file. When
you use XXCOPY to transfer files from one file system to another,
you should be aware of the characteristics of the file system.
The granularity of the file time maintained by the OS is the
first one to note:
File System File time granularity
FAT12/FAT16/FAT32 2 sec
NTFS 100 nsec
Unix/Linux 1 sec
If your XXCOPY operation does not check the file time as the
criteria for file selection, the granularity is not an issue.
However, when you use an operation which involves the file time,
you should know more. The following list shows the switches
which depend on the time stamp of the file.
/BI Backup Incremental
/BN Backup Newer files
/Bo Backup Older files
/BS Backup Same-time/size files
/BX Backup Different-time/size files
/BU Backup (combination using /BI)
/DA Copies Newer files
/DB Copies Older files
/DS Copies Same-time files
/DX Copies Different-time files
/CLONE Backup (combination using /BI)
The best way to handle such a case with mixed file systems is
to use the /FF (Fuzzy Filetime) switch. With the switch, XXCOPY
will ignore the difference in filetime values for up to 2 seconds
to accommodate the granularity difference in file time among
various file systems.
3. Remaining space check.
Ideally speaking, a file copy utility should know the remaining
space on the destination before a copy operation is started.
That is exactly what XXCOPY does. However, when the destination
directory is on a remote machine, the value XXCOPY receives as
the remaining space from the Operating system is sometimes
not accurate. When this happens, XXCOPY terminates the current
session and returns the "Disk Full" error condition.
Many users have reported that XXCOPY prematurely terminates
a session due to a false reading on the remaining space. That
is, XXCOPY's idealistic design backfires --- and the more
primitive design (e.g., the COPY command) works better by not
checking the remaining space. So, you can override XXCOPY's
pre-check feature by /CK0 (default is /CK).
4. Time stamp type, and locality .
The original FAT12 and FAT16 file systems used by DOS had only
one type of file time which represents the last-modified time.
The FAT32 and NTFS maintain three types of time stamps for each
Time when the file was Last-modified (/FW default)
Time when the file was First-created (/FC)
Time when the file was Last-accessed (/FA)
By default, XXCOPY uses the Last-modified value as the file
The file time is referenced either by the local time or by the
universal time (UTC, also known as GMT). The default setting
uses the local time since most of us eat lunch at Noon(?).
The setting is either /FL (Local, default) and /FU (UTC).
Since we do not hear much problems associated with the
time-representation aspects, we assume this is not a serious
issue with XXCOPY. But, XXCOPY is prepared to deal with it.
See article: XXTB #15, for related topics.
In this article, a few solutions are provided to alleviate
common problems dealing with XXCOPY operation across networked
drives. The solutions listed here generally works. However,
they are only a guideline and your case may involve other
factors which are overlooked in this article.
Please note that this article does not cover all common pitfalls.
We welcome your feedback when you encounter similar problems
which we have not yet addressed.
Please send E-Mail to
[ Table of Contents ]
[ << ]
[ Show as Detached ]
[ >> ]