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:
/L /V
- huge number of changed (but actually identical) files are listed, 2309 skipped files according to log summary.
/L /V /XC
- no changed files are listed, 2309 skipped files according to log summary.
/L /XC
- no changed files are listed, 2309 skipped files according to log summary.
/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.
>
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 – 2014-01-30T03:52:25.703