Robocopy Appears to be Broken in Windows 8

Robocopy appears to be broken in windows 8. It flags a number of files as "modified" even when they are not. The "modified" seems to happen when a source file has been accessed. With a NTFS target the "modified" is satisfied; however, on Fat32 or apple file systems, it is never satisfied and will always appear on subsequence runs.

I use these settings in my CMD file.
/mir /r:0 /w:0 /xo /ndl /log+:%robocopytempfile% /tee

Has anyone found a work around yet?

The only solution I can find at this time is to run the robocopy located in the Win2003 Resource Kit.
 

Question Info


Last updated November 27, 2019 Views 18,786 Applies to:

* Please try a lower page number.

* Please enter only numbers.

* Please try a lower page number.

* Please enter only numbers.

Robocopy appears to be broken in windows 8. It flags a number of files as "modified" even when they are not. The "modified" seems to happen when a source file has been accessed. With a NTFS target the "modified" is satisfied; however, on Fat32 or apple file systems, it is never satisfied and will always appear on subsequence runs.
I use these settings in my CMD file.
/mir /r:0 /w:0 /xo /ndl /log+:%robocopytempfile% /tee
Has anyone found a work around yet?
The only solution I can find at this time is to run the robocopy located in the Win2003 Resource Kit.
I found it.  It's the ARCHIVE attribute on the source files.  On the new Robocopy, the presence of the "A" attribute seems to force the file to be copied.  The problem is, Robocopy doesn't then reset the attribute. 

And if you use /M (copy only "A" files, then reset "A"), any files without the "A" attribute set get ignored - even if they should have been copied because they don't exist on the target, etc.  So that doesn't work.

The solution "appears" to be to reset the "A" attribute on the structure you want to copy BEFORE you do the copy.  Then your script "should" work.  (Mine did.)  I used:
ATTRIB -A C:\MYDIR\*.* /D /S to clear the attributes.  Then Robocopy started working.

Of course, going forward, modified files will get "A" set, and then Robocopy will start copying those files every time again, so what I did was to add the ATTRIB command AFTER the Robocopy command in my script.  Run Robocopy, then reset "A"s.  That "should" yield the desired result, I hope!

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

Thanks for the reply. Your idea of the /M works. I have to admit, I would prefer a cleaner solution.

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

Robocopy appears to be broken in windows 8. It flags a number of files as "modified" even when they are not. The "modified" seems to happen when a source file has been accessed. With a NTFS target the "modified" is satisfied; however, on Fat32 or apple file systems, it is never satisfied and will always appear on subsequence runs.
I use these settings in my CMD file.
/mir /r:0 /w:0 /xo /ndl /log+:%robocopytempfile% /tee
Has anyone found a work around yet?
The only solution I can find at this time is to run the robocopy located in the Win2003 Resource Kit.
I found it.  It's the ARCHIVE attribute on the source files.  On the new Robocopy, the presence of the "A" attribute seems to force the file to be copied.  The problem is, Robocopy doesn't then reset the attribute. 

And if you use /M (copy only "A" files, then reset "A"), any files without the "A" attribute set get ignored - even if they should have been copied because they don't exist on the target, etc.  So that doesn't work.

The solution "appears" to be to reset the "A" attribute on the structure you want to copy BEFORE you do the copy.  Then your script "should" work.  (Mine did.)  I used:
ATTRIB -A C:\MYDIR\*.* /D /S to clear the attributes.  Then Robocopy started working.

Of course, going forward, modified files will get "A" set, and then Robocopy will start copying those files every time again, so what I did was to add the ATTRIB command AFTER the Robocopy command in my script.  Run Robocopy, then reset "A"s.  That "should" yield the desired result, I hope!

Thank you so much; I had that same problem and your solution works! The only caveat is that the ATTRIB command seems to be very choosy with pathnames: if there are any spaces in a directory name it doesn't seem to recognize the path.

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

I mentioned earlier that it worked, but now it seems like it doesn't! For certain directories it copies every file, modified or not. When I try resetting ATTRIB on them by hand, without a batch file, using the command you provided, it seems to work just fine. Then Robocopy still copies every file! But for other directories, it skips the files as expected. There seems to be no rhyme or reason as to why it does this, and the problem is unique to Windows 8; Windows 7 and XP (SP3) work just fine. Thank you so much, however, for putting your finger on at least part of the problem so far.

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

I've been using robocopy.exe for years on Win2k, WinXP, Vista and Win7 for daily scripted backups of selected files on my home PCs. The scripts copy from the PC's boot drive to another internal drive. (Other scripts copy files offsite.)

I've seen the same Win8 robocopy problem that others have reported here. I appreciate Rocker-Rubino's suggestion to try a much older robocopy.exe. I tried the Win7 version and found that it still has the same problem. I'll give the WinXP version a try.

In trying the Win7 version, I experienced another anomaly: If my scripts call the Win7's robocopy.exe in the folder where the Win8 upgrade installer left it -- c:\windows.old\windows\system32 -- it runs cosmetically normally while displaying the excessive copying problem we're discussing here. If I move the Win7 robocopy.exe to another folder -- c:\myscripthome -- it shows an additional cosmetic problem: Robocopy's  console logging is made without line feeds, causing the console to be more or less unreadable. This seems fairly odd. (FWIW, I'm using the "tee" parameter and haven't tried the script without it.)

An aside: In reading up on Win8's robocopy, I noticed a change that I'll make use of eventually: Robocopy now has the /J parameter for unbuffered file copying that Win7's xcopy introduced. Unbuffered copying speeds up large file transfers. Useful when moving .vhd files and such around.



Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

The one from W7 will not help you. Please use the one from the Server 2003 Resource Kit.

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

I installed the Win2K3 version in a backup script this morning and it seemed to work OK in script runs today. At least, the scripts ran with the expected speed, rather than getting bogged down copying thousands of unchanged files.

(I was thinking that robocopy came with WinXP. I see now that it did not, but the Win2K3 version worked on WinXP.)

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

Thank you. I installed the one from the resource kit you mentioned on my Windows XP machine (which doesn't have Robocopy) as well as on my Windows 8 machine, on which I gave the robocopy.exe file from the resource kit a slightly different name, and it's been working just fine.

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

Happy to help!

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

I'm sure that I don't fully understand what's going on yet, but here's some additional info I discovered through trial and error:

Clearing the archive attribute flag on the source doesn't seem to fully stop Robocopy v6.2 (included in Windows 8) from finding "Modified" files and copying them.

The "/A-:A" switch (which should remove the archive attribute form the copied files) seems to have no effect (at least when used over network).

If I later modify the attribute(s) of relevant file(s) on either side, running the same Robocopy command will cause it to detect "Modified" files again, even if I (and especially if I do) change the attributes to be same between both sides.

But, if I remove the archive attribute from all relevant files on the host side (the computer running the Robocopy command) and actually set the the archive attribute on those files on the guest (for lack of a better term) side, then Robocopy won't detect the files as "Modified" and otherwise work as expected.  Interestingly, the reverse seems to work as well (setting Archive on host & clearing on guest).  So, there seems to be some messed up detection logic for "Modified" files over a network.


TLDR: To get the new Robocopy to reliably not copy "Modified" files over a network, CLEAR the Archive attribute of files in the set on the host side and SET the Archive attribute of those files on the other side before running Robocopy.

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

* Please try a lower page number.

* Please enter only numbers.

* Please try a lower page number.

* Please enter only numbers.