RoboCopy sees two files as changed when they are exactly the same

Question

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)

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.