I have the following xcopy command to back up only the new files in Windows Server 2008 box:

XCOPY /D /Y C:\TMP\*.dat C:\Test

it works fine first time to copy all the files to Test and copy nothing subsequently since no files have been changed in C:\TMP.

However, I tried the same command to a network drive (exported drive for Windows from LINUX, the connection is CIFS), the XCOPY does copy all the files no matter the source files are changed or not. The similar command is like this:

XCOPY /D /Y C:\TMP\*.dat Z:\Test

I verified files in C:\test and Z:\Test by date time and property pages. All the dates for creating, modified and accessed ones are the same.

The purpose I need to use XCOPY is to do incremental back up of files. I also tried to use ROBOCopy (a tool in Windows kit), the same behavior: working as expected in local drives but not for the network drive.

Another reason I like XCOPY is that the new source files are copied to even when the source file are hold by other processes. I tried Microsoft SyncToy, but it does not work in this case. Based on doc for ROBOCopy, it seems it does not work for files hold by process neither.

If the network drive is a network drive on another Windows box, the XCOPY works fine. It seems that XCOPY does not work for imported drives from UNIX system. Not sure why or if there are any other options I missed? Or any other option or tools available?

  • What technology exactly are you using for the Windows to Linux connection? Are you using Samba, NFS, or something else?
    – Zoredache
    Sep 3 '10 at 22:01
  • Just net use command such as net use Z: \\device\spacedir pwd /user:domain\user1. My network team set the device space for me. Sep 3 '10 at 22:07
  • See my updated question, it is CIFS connection. Sep 3 '10 at 22:38

I suspect the difference lay in date resolution differences as reported by Samba and as stored in the file-system. It could be that Samba is reporting dates with the micro-seconds zeroed, where the file-system is storing microseconds, and xcopy/robocopy care about that. Without cracking open a sniffer I can't prove it, but it is a guess.

  • I agree with you that it may be the case to cause the problem. From Property view for the files, I can only see date and time up to seconds. No more information after seconds. So xcopy may just pass partial time information to the network drive. Now I find out that with /M option to reset archive flag xcopy works as expected. When source files are updated again, I think the archive flag is reset again. I guess that /M is similar as /D as default. With /D, specified date can be specified. Sep 7 '10 at 22:35

The Samba map archive and create mask options control whether or not the archive bit is stored. They may have been frobbed/disabled for security reasons.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.