Xcopy /D copies all files, not just newer

  • Thread starter Thread starter Mike C
  • Start date Start date
M

Mike C

I am trying to use a batchfile to backup from a PC to a NAS. I am
using the /D switch, and the files are mostly months newer on the NAS,
but it still wants to copy them all. Anyone know why or how to
workaround this?
 
Hi, Mike.

In the Command Prompt window, type: xcopy /?

If you already did this, then what is the exact form of your command line?
Did you insert a date, such as:
xcopy /d:07-31-08

I don't use the /d switch much; does it require a 4-digit year? Are you
perhaps using the d-m-y format, rather than m-d-y? Or / instead of - for
the separators?

I'm about out of guesses. Could you supply more details? Some examples,
perhaps?

RC
--
R. C. White, CPA
San Marcos, TX
(e-mail address removed)
Microsoft Windows MVP
Windows Live Mail 2009 (14.0.8064.0206) in Win7 Ultimate x64 RC 7100
 
The /d switch, without specifying a date, is supposed to overlay only older
files.
BTW - that format doesn't use a colon.

example extracted and simplified from my own backup command file, which
backs up my Data drive (M) to a USB drive:

XCOPY M:\* U:\Backups /d/e/c/i/r/k/o/y

***
 
Thanks. Using robocopy worked perfectly. I didn't realize xcopy was
deprecated.
Click to expand...

There's also something called xxcopy, which I guess is a competitor of
Robocopy.

Since I rarely or never use them, I'm no expert - just mentioning an
alternative for anyone who cares :-)
 
Gene E. Bloch said:
There's also something called xxcopy, which I guess is a competitor of
Robocopy.

Since I rarely or never use them, I'm no expert - just mentioning an
alternative for anyone who cares :-)
Click to expand...

There's always an alternative. If you're already writing a batch file you
could just write a VBscript file instead and use the file system objects.
 
Hi,

Sincexcopyis deprecated, try usingrobocopy:http://technet.microsoft.com/en-us/library/cc733145(WS.10).aspx

--
Best of Luck,

Rick Rogers, aka "Nutcase" - Microsoft MVPhttp://mvp.support.microsoft.com/
Windows help -www.rickrogers.org
Vote for my shoe:http://rick-mvp.blogspot.com
Click to expand...

I take it back that Robocopy worked. Using the /XO switch to exclude
older files, it still wants to copy files that have the exact
timestamp on them. I verified this on several files and the
timestamps are the same to the second. Oddly, it isn't on all files,
but a lot of them.
 
There's always an alternative.  If you're already writing a batch file you
could just write a VBscript file instead and use the file system objects.
Click to expand...

I am a programmer, but have no idea why you would want to reinvent the
wheel.

XXCOPY I have used before, but like to use built-in commands/utilities
if possible so that my batchfiles are portable without installing a
lot of extra software.
 
There's always an alternative. If you're already writing a batch file you
could just write a VBscript file instead and use the file system objects.
Click to expand...
-
-I am a programmer, but have no idea why you would want to reinvent the
-wheel.
-
-XXCOPY I have used before, but like to use built-in commands/utilities
-if possible so that my batchfiles are portable without installing a
-lot of extra software.

OP already said they were writing a batch file, so I recommend vbscript.
What wheel is that reinventing? Does XXCOPY make batch files?
vbscript is native to Windows, no extra software to install.
Why use built in commands if the issue here is a built in command was
deprecated and needs a replacement?
 
-
-I am a programmer, but have no idea why you would want to reinvent the
-wheel.
-
-XXCOPY I have used before, but like to use built-in commands/utilities
-if possible so that my batchfiles are portable without installing a
-lot of extra software.

OP already said they were writing a batch file, so I recommend vbscript.
What wheel is that reinventing?  Does XXCOPY make batch files?
vbscript is native to Windows, no extra software to install.
Why use built in commands if the issue here is a built in command was
deprecated and needs a replacement?
Click to expand...

Well, Xcopy and Robocopy have around 50 switches. That can be written
in vb script easily?

When I said using in a batchfile, it is just a simple batch file with
3 robocopy commands.
 
-
-I am a programmer, but have no idea why you would want to reinvent the
-wheel.
-
-XXCOPY I have used before, but like to use built-in commands/utilities
-if possible so that my batchfiles are portable without installing a
-lot of extra software.

OP already said they were writing a batch file, so I recommend vbscript.
What wheel is that reinventing? Does XXCOPY make batch files?
vbscript is native to Windows, no extra software to install.
Why use built in commands if the issue here is a built in command was
deprecated and needs a replacement?
Click to expand...
-
-Well, Xcopy and Robocopy have around 50 switches. That can be written
-in vb script easily?
-
-When I said using in a batchfile, it is just a simple batch file with
-3 robocopy commands.

Why are your posts broken (when I reply it doesn't add the > in front)?

I don't know how easy it is to program for 50 switches. That depends on
your programming expertise and which switches you use. I don't normally use
any switches for robocopy.

If it's a simple batch file with 3 commands, your simplest option should be
replacing your xxcopy statements with robocopy statements, assuming the
machine it's going to run on will have the robocopy and you're not worried
about another utility becoming deprecated. I use robocopy on XP pro and it
didn't come with it. Your original post said batch file, didn't say simple
3 statement batch file. Converting a more complicated batch file to a
program could save some headaches later.
 
-
-Well,Xcopyand Robocopy have around 50 switches. That can be written
-in vb script easily?
-
-When I said using in a batchfile, it is just a simple batch file with
-3 robocopy commands.

Why are your posts broken (when I reply it doesn't add the > in front)?

I don't know how easy it is to program for 50 switches.  That depends on
your programming expertise and which switches you use.  I don't normally use
any switches for robocopy.

If it's a simple batch file with 3 commands, your simplest option should be
replacing your xxcopy statements with robocopy statements, assuming the
machine it's going to run on will have the robocopy and you're not worried
about another utility becoming deprecated.  I use robocopy on XP pro and it
didn't come with it.  Your original post said batch file, didn't say simple
3 statement batch file.  Converting a more complicated batch file to a
program could save some headaches later.
Click to expand...

I appreciate all the responses. I am guessing though that there is
some simple reason why robocopy isn't working. I assume that a utility
that Microsoft has included for 10 years works and there is just some
caveat why it isn't working in my case (maybe because of NAS?).
 
- I appreciate all the responses. I am guessing though that there is
- some simple reason why robocopy isn't working. I assume that a utility
- that Microsoft has included for 10 years works and there is just some
- caveat why it isn't working in my case (maybe because of NAS?).

Is robocopy copying files?
Did I read this right that your issue is robocopy not copying files which
haven't changed?
Did you check the switches? Did you try /IS?
 
I take it back that Robocopy worked. Using the /XO switch to exclude
older files, it still wants to copy files that have the exact
timestamp on them. I verified this on several files and the
timestamps are the same to the second. Oddly, it isn't on all files,
but a lot of them.
Click to expand...

I don't remember about Windows, but I recall that Unix file time stamps are
recorded to the millisecond. If this is true in NTFS, two files could seem
to have the same age while one is in fact older, when the display is only
to the second.

Now ask me whether I believe that is happening here...
 
I don't remember about Windows, but I recall that Unix file time
stamps are recorded to the millisecond. If this is true in NTFS, two
files could seem to have the same age while one is in fact older, when
the display is only to the second.

Now ask me whether I believe that is happening here...
Click to expand...

This can happen when copying between drives where one is formatted in
NTFS and the other is FAT - the time is stored to different resolutions,
and may also be stored with differing timezones (DST vs standard time, or
UCT vs local time).
 
File Times
A file time is a 64-bit value that represents the number of 100-nanosecond
intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated
Universal Time (UTC). The system records file times when applications
create, access, and write to files.

The NTFS file system stores time values in UTC format, so they are not
affected by changes in time zone or daylight saving time. The FAT file
system stores time values based on the local time of the computer. For
example, a file that is saved at 3:00pm PST in Washington is seen as 6:00pm
EST in New York on an NTFS volume, but it is seen as 3:00pm EST in New York
on a FAT volume.

Timestamps are updated at various times and for various reasons. The only
guarantee about a file timestamp is that the file time is correctly
reflected when the handle that makes the change is closed.

Not all file systems can record creation and last access times, and not all
file systems record them in the same manner. For example, the resolution of
create time on FAT is 10 milliseconds, while write time has a resolution of
2 seconds and access time has a resolution of 1 day, so it is really the
access date. The NTFS file system delays updates to the last access time for
a file by up to 1 hour after the last access.
 
File Times
A file time is a 64-bit value that represents the number of 100-nanosecond
intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated
Universal Time (UTC). The system records file times when applications
create, access, and write to files.

The NTFS file system stores time values in UTC format, so they are not
affected by changes in time zone or daylight saving time. The FAT file
system stores time values based on the local time of the computer. For
example, a file that is saved at 3:00pm PST in Washington is seen as 6:00pm
EST in New York on an NTFS volume, but it is seen as 3:00pm EST in New York
on a FAT volume.

Timestamps are updated at various times and for various reasons. The only
guarantee about a file timestamp is that the file time is correctly
reflected when the handle that makes the change is closed.

Not all file systems can record creation and last access times, and not all
file systems record them in the same manner. For example, the resolution of
create time on FAT is 10 milliseconds, while write time has a resolution of
2 seconds and access time has a resolution of 1 day, so it is really the
access date. The NTFS file system delays updates to the last access time for
a file by up to 1 hour after the last access.
Click to expand...

Thanks, <dot> and < >.

Looks like my guess might have actually been right (not in detail, but in
outline).

And I was just kidding about the new forms of your names - no offense was
intended.
 
File Times
A file time is a 64-bit value that represents the number of 100-nanosecond
intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated
Universal Time (UTC). The system records file times when applications
create, access, and write to files.

The NTFS file system stores time values in UTC format, so they are not
affected by changes in time zone or daylight saving time. The FAT file
system stores time values based on the local time of the computer. For
example, a file that is saved at 3:00pm PST in Washington is seen as 6:00pm
EST in New York on an NTFS volume, but it is seen as 3:00pm EST in New York
on a FAT volume.

Timestamps are updated at various times and for various reasons. The only
guarantee about a file timestamp is that the file time is correctly
reflected when the handle that makes the change is closed.

Not all file systems can record creation and last access times, and not all
file systems record them in the same manner. For example, the resolution of
create time on FAT is 10 milliseconds, while write time has a resolution of
2 seconds and access time has a resolution of 1 day, so it is really the
access date. The NTFS file system delays updates to the last access time for
a file by up to 1 hour after the last access.

--
.
--
I don't remember about Windows, but I recall that Unix file time stamps
are
recorded to the millisecond. If this is true in NTFS, two files could seem
to have the same age while one is in fact older, when the display is only
to the second.
Click to expand...
Now ask me whether I believe that is happening here...
Click to expand...
Click to expand...

There is a switch that accomodates an 1 hour time zone difference (/
dst) . Even with that, robocopy still insists on copy files that have
the same time (at the resolution that I can see). I see there is a
FAT time switch (/fft - assumes FAT file times (two-second
granularity) - I will try that when I get home.

I am almost positive both volumes are formatted NTFS and will verify
that.
 
File Times
A file time is a 64-bit value that represents the number of 100-nanosecond
intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated
Universal Time (UTC). The system records file times when applications
create, access, and write to files.

The NTFS file system stores time values in UTC format, so they are not
affected by changes in time zone or daylight saving time. The FAT file
system stores time values based on the local time of the computer. For
example, a file that is saved at 3:00pm PST in Washington is seen as 6:00pm
EST in New York on an NTFS volume, but it is seen as 3:00pm EST in New York
on a FAT volume.

Timestamps are updated at various times and for various reasons. The only
guarantee about a file timestamp is that the file time is correctly
reflected when the handle that makes the change is closed.

Not all file systems can record creation and last access times, and not all
file systems record them in the same manner. For example, the resolution of
create time on FAT is 10 milliseconds, while write time has a resolution of
2 seconds and access time has a resolution of 1 day, so it is really the
access date. The NTFS file system delays updates to the last access time for
a file by up to 1 hour after the last access.
Click to expand...
Hi,
Click to expand...
Sincexcopyis deprecated, try
usingrobocopy:http://technet.microsoft.com/en-us/library/cc733145(WS.10).aspx
Click to expand...
Rick Rogers, aka "Nutcase" - Microsoft
MVPhttp://mvp.support.microsoft.com/
Windows help -www.rickrogers.org
Vote for my shoe:http://rick-mvp.blogspot.com
Click to expand...
I am trying to use a batchfile to backup from a PC to a NAS. I am
using the /Dswitch, and the files are mostly months newer on the NAS,
but it still wants to copy them all. Anyone know why or how to
workaround this?
Click to expand...
I take it back thatRobocopyworked.  Using the /XO switch to exclude
older files, it still wants to copy files that have the exact
timestamp on them.  I verified this on several files and the
timestamps are the same to the second.  Oddly, it isn't on all files,
but a lot of them.
Click to expand...
I don't remember about Windows, but I recall that Unix file time stamps
are
recorded to the millisecond. If this is true in NTFS, two files could seem
to have the same age while one is in fact older, when the display is only
to the second.
Click to expand...
Now ask me whether I believe that is happening here...
Click to expand...
Click to expand...

There is a switch that accomodates an 1 hour time zone difference (/
dst) . Even with that, robocopy still insists on copy files that have
the same time (at the resolution that I can see). I see there is a
FAT time switch (/fft - assumes FAT file times (two-second
granularity) - I will try that when I get home.

I am almost positive both volumes are formatted NTFS and will verify
that.[/QUOTE]

The FAT switch sounds worth a try...Excellent detective work :-)

I still won't bet that my guess was right, but at least it wasn't bad
(i.e., it wasn't completely off the wall).
 
Back
Top