Robocopy Appears to be Broken in Windows 8

Question

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.

Answer 1

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!

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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.