XCOPY /D
Ritchie
I was exploring various ways of syncing the contents
of two folders using _pure batch_, and I thought I was
getting somewhere until I started using the /D switch
with XCOPY.EXE on W2K(SP2).
This is what the commandline help says about /D
"Copies files changed on or after the specified date.
If no date is given, copies only those files whose
source time is newer than the destination time."
And the GUI help says
"This option allows you to update only files that have
changed"
I would take this to mean that if I use /D on its own
(i.e. without a date) then the destination file will
be overwritten only if it is older than the source file.
Wouldn't you?
As can be seen below, the file '\data\a' on d: and f:
has the same date and time, but xcopy insists on over-
writing the copy on f: with the copy on d:
I'm I missing something???
Ritchie
PS Don't tell me about Robocopy or XXcopy
================= start screen capture =================
C:\>dir d:\data\a
Volume in drive D is Data
Volume Serial Number is 549E-D90B
Directory of d:\data
22/01/2002 17:58 1,101 a
1 File(s) 1,101 bytes
0 Dir(s) 9,410,252,800 bytes free
C:\>dir f:\data\a
Volume in drive F is BACKUP05
Volume Serial Number is E34C-9928
Directory of f:\data
22/01/2002 17:58 1,101 a
1 File(s) 1,101 bytes
0 Dir(s) 32,243,712 bytes free
C:\>xcopy d:\data\a f:\data /d /y
D:\data\a
1 File(s) copied
C:\>xcopy d:\data\a f:\data /d /y
D:\data\a
1 File(s) copied
================== end screen capture ===============
Herbert Kleebauer
>
> As can be seen below, the file '\data\a' on d: and f:
> has the same date and time, but xcopy insists on over-
> writing the copy on f: with the copy on d:
>
> I'm I missing something???
Maybe one drive is ntfs and the other fat?
> PS Don't tell me about Robocopy or XXcopy
Even if you don't want to use these programs, you shouldn't ignore
the information you can get from them (the same is true for non
batch solutions). The following is from the xxcopy documentation:
/FT (File time truncation)
When file time is compared against one another in a mixed OS
environment, the granularity of the file time stamp (which is
usually set by the particular file system) may cause problems.
For example, the FAT based file systems (FAT12, FAT16, FAT32)
uses file time which is measured by two second interval whereas
unix-based file system uses one second interval. The NTFS uses
much finer file time. The /FT switch forces XXCOPY to truncate
a file time to the coarsest (two second interval) unit before
file times are compared.
Kan Yabumoto
1. xcopy c:\mysrcdir\ d:\mydstdir\ /d
without an argument, /d will compare between the files in the source
and the one in the destination (for the same name file as a pair)
and copies only when the one in the source is newer.
2. xcopy c:\mysrcdir\ d:\mydstdir\ /d:10-31-2001
with a parameter following the /d switch (separated by a colon)
files with the timestamp on or after the specified date.
(I believe the date specifier of XCOPY follows the American
notation of m-d-y)
Ritchie's question about the files being overwritten by the
same file as if the /d switch is ignored. My guess is that
the reason is the one volume is a FAT volume and the other one
is an NTFS volume. The granularity (the finest increment of the
timestamp) is 2 seconds for a FAT volume and 0.1 microsecond
for an NTFS volume. I venture to guess that the destination
(F:) is probably FAT-based which cannot keep the same granularity
as the source (D: which I guess is NTFS) and therefore the
timestamp has to go through a conversion.
I'm puzzled by Richies comment
"PS Don't tell me about Robocopy or XXcopy"
Because either Robocopy or XXCOPY has a feature to overcome
the timestamp-granularity problem (Robocopy ignores time difference
within 2 seconds and XXCOPY even has control on the range of
difference in determining the time-unity), whereas XCOPY is too
dumb to handle such a case. Of course, they could be intimidating.
Sorry if you already knew that these tools had the solution for you.
Kan Yabumoto
=====================================================================
"Ritchie" <dontg...@enildnammoc.co.uk> wrote in message news:<3c4da...@mk-nntp-1.news.uk.worldonline.com>...
Ritchie
news:3C4DD22E...@unibwm.de...
Thank you, please see my reply to Kan Yabumoto (to avoid saying the
same thing twice).
Ritchie
Ritchie
news:4e377a72.02012...@posting.google.com...
>
> Ritchie's question about the files being overwritten by the
> same file as if the /d switch is ignored. My guess is that
> the reason is the one volume is a FAT volume and the other one
> is an NTFS volume. The granularity (the finest increment of the
> timestamp) is 2 seconds for a FAT volume and 0.1 microsecond
> for an NTFS volume. I venture to guess that the destination
> (F:) is probably FAT-based which cannot keep the same granularity
> as the source (D: which I guess is NTFS) and therefore the
> timestamp has to go through a conversion.
Kan, Herbert,
You're both quite right. I've confirmed the /D switch works as
expected when copying from my FAT32 volume to NTFS, but not from
NTFS to a CD-RW (CDRF???)
> I'm puzzled by Richies comment
>
> "PS Don't tell me about Robocopy or XXcopy"
Don't be. History as shown that questions similar to mine are
usually answered with one-liners; "Use RoboCopy or XXCOPY".
I wasn't trying to solve a real practical problem but trying
to understand why the /D wasn't performing as expected.
> Because either Robocopy or XXCOPY has a feature to overcome
> the timestamp-granularity problem (Robocopy ignores time difference
> within 2 seconds and XXCOPY even has control on the range of
> difference in determining the time-unity), whereas XCOPY is too
> dumb to handle such a case. Of course, they could be intimidating.
> Sorry if you already knew that these tools had the solution for you.
Apology accepted :)
Thank you both for taking the time to explain. Much appreciated.
I'm left wondering why MS bothered including XCOPY, as this
limitation renders it virtually useless.
Ritchie
l...@bounceit.net
I believe xcopy was developed because COPY was so bad (copies one file
at a time).
Its still there for compatibility.
LB