Using RoboCopy I am copying large sets of files between storage devices and have noticed some strange behavior: On many occasions where the source and destination file are the same, RoboCopy sees the file as changed and copies it again. I have verified that the size and date of the files are the same. I am using the below command. The version of RoboCopy being used is from Vista/Windows 2008.

robocopy "W:\SourceFolder" "Q:\Destination Folder" /E /R:2 /W:5 /NP /LOG+:%1 /tee /fft /purge 

The /FFT switch used here often fixes this problem - but not here - (as in these pages addressing the same question: Robocopy falsely marks files as newer which itself refers to Robocopy Incorrectly Detects Files as Newer When Copying Between Different File Systems)

  • 1) Is there anything in the Robocopy output that might explain it? 2) As a test, for one of those "strange" files, if you delete the file at the destination, then run your Robocopy command to restore the file, do further uses of Robocopy still attempt to re-copy that file? Jan 29, 2014 at 23:41
  • The project is long over now. The original copy was done by robocopy so the basic answer to you delete and allow to copy again would be yes. I did not see any output other than "changed"
    – Brettski
    Jan 30, 2014 at 3:52

1 Answer 1


The observed behavior could be the result of a reporting issue in Robocopy.

I can reproduce the following with the Windows 10 version of Robocopy: I run robocopy on two almost identical directories using the /L switch, i.e. no changes are made, only the actions that would occur if the job was actually executed are logged as specified. I compared the file lists and numbers of skipped files reported in the logs for the following combinations of switches /V (verbose log, listing also skipped files) and /XC (skip files tagged as changed) and otherwise default behaviour:

  1. /L /V - huge number of changed (but actually identical) files are listed, 2309 skipped files according to log summary.
  2. /L /V /XC - no changed files are listed, 2309 skipped files according to log summary.
  3. /L /XC - no changed files are listed, 2309 skipped files according to log summary.
  4. /L- no changed files are listed, 2309 skipped files according to log summary.

The number of skipped files is exactly the same in all 4 runs, regardless of the application of the /XC switch. If the files categorized as Changed in the verbose log in run 1 were actually to be copied then I'd expect to see them listed in the log for run 4 and I'd expect a larger number of skipped files being reported in runs 2 and 3 when (actually) changed files are skipped, compared to runs 1 and 4, when they aren't.

My conclusion is that for some reason, in the verbose log, robocopy labels files with identical size and time stamps as changed but doesn't actually treat them as such and, in particular, doesn't copy them.

Of course, this still doesn't explain why those files are tagged as changed in the first place.

  • 1
    Thank you for the feedback on this really old question! Due to these oddities, when a copy/sync really mush be 100% right, I use Beyond Compare. It's that feeling of knowing it will be right. :)
    – Brettski
    Dec 12, 2018 at 18:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .