Robocopy Bug
I found the following strange behavours of the new robocopy included in Windows 2008 R2. Say I have one source and one target on my computer. If I do the following command the first time: robocopy d:\source d:\target /copyall /mir /e /m I will get the files in source copied to the target. Good. Now, if I run a backup program and clear the archive attribute in the target folder, and re-run the above command, I will see in the summary that nothing got copied since there's no changes. Good. However, if I run a attrib * on the target folder, I will see that all the files have A attributes again! Robocopy says it did not touch those files, but in fact it put A in the attribute. I did more tests and find out if I run the following line, A won't be changed for unchanged files: robocopy d:\source d:\target /copy:dtou /mir /e /m But as soon as I include s in the copy option for security information, like the following: robocopy d:\source d:\target /copy:dtsou /mir /e /m A attribute got added to all the files in target. I did the same test on a XP/2003 machine with the older version of robocopy, and they are all fine. Looks like a problem introduced by the new version of robocopy. Can anybody confirm and suggest any fix? Thanks a lot.
September 22nd, 2010 12:53pm

Hi, This is logged in Microsoft database. Here are the explanation: The archive bit is used by some backup apps to determine whether to backup a file as part of an incremental or differential backup. Apps that use this backup everything on the first full and then clear the archive bit on the backed up files. When subsequent changes happen to a file, the archive bit is set again. For the next backup, the app only backs up files where the bit is set. You can even define the difference between differential and incremental based on whether the archive bit is subsequently cleared. For your case, it sounds like you are doing the right thing. If you are backing up the new servers, then you want the newly arrived files to get backed up even if those files had already been backed up elsewhere.Shaon Shan| TechNet Subscriber Support in forum| If you have any feedback on our support, please contact tngfb@microsoft.com
Free Windows Admin Tool Kit Click here and download it now
September 24th, 2010 4:29am

Yes, I understood how the archive bit works. The problem here is, the new version of robocopy set archive to be on for even files that have not chagned since last copy. This happens if I include security group in the copy option, like /copyall or /copyall:dtsou. So although robocopy did not re-copy everything from the source to the target, it flags all the archive bit on for the files in the target. This was not the case in the older version of robocopy. Only the ones come with Windows Server 2008. So I'd like to find out what's going on here. Thanks.
September 24th, 2010 8:40am

Hi, I have sent an email to the engineer who create the case in Microsoft database to see if there is any update. If a reply is arrived I will post back. Meanwhile I will report the case to see if it will be considered as a bug. Thank you for your time.Shaon Shan| TechNet Subscriber Support in forum| If you have any feedback on our support, please contact tngfb@microsoft.com
Free Windows Admin Tool Kit Click here and download it now
September 27th, 2010 3:17am

Howdy, I seem to also be experiencing a similar problem, but my issue is with the SOURCE folder and I am using Windows 7x64. I backup to several different locations. I previously used xcopy to performs backups using the /A and /M switch. Yesterday I thought I would convert over to robocopy instead. Now, I use the /A to copy only files with archive bit set and the last copy uses the /M switch to clear the SOURCE files archive bit. Works with xcopy, does not work with robocopy. The commands I would be using appear as such: robocopy "C:\Test Folder" "D:\Test Folder" /E /A /V /R:5 /W:5 robocopy "C:\Test Folder" "H:\Test Folder" /E /M /V /R:5 /W:5 I don't believe I am doing anything wrong here. I await your response to Chen is the hope it will also solve my issue. Thank you Hesh
September 29th, 2010 8:04pm

I will report it to related department. The behavior can be a little confusing and may be considered as a bug.Shaon Shan| TechNet Subscriber Support in forum| If you have any feedback on our support, please contact tngfb@microsoft.com
Free Windows Admin Tool Kit Click here and download it now
October 7th, 2010 10:27pm

I already started a new thread for this, when someone pointed me to this thread. Because I think my issue is a different from the behaviours described above, I'll just past my entire post here: I'm running robocopy version 5.1.10.1027 on a Windows 2008 Storage server (64 bits). I use Robocopy to create full backups in the weekend, and differentials on weekdays. In the weekends, I run Robocopy with the parameter /a-:a to clear the Archive attribute. During the week, I only copy the files with the Archive flag set (by specifying the /a parameter). The /a-:a parameter works fine, except that it does not clear the Archive flag for files that are hidden. The hidden files are copied without a problem (both in the full as in the incremental run), it's just the archive flag that does not get cleared. This issue causes my differential backups to be a bit bigger then expected, because the hidden files (no matter how old they are) are always copied, since the archive bit is not being cleared. Thanks! Martijn
October 26th, 2010 5:09am

Is there an answer to this yet? I am seeing the same problems here too (Win7x64) Michael
Free Windows Admin Tool Kit Click here and download it now
February 3rd, 2011 4:17am

I noticed this problem only occured when I use the /MIR option. When I use /E /PURGE /COPYALL (wich is the same as /MIR ;) ) then this problem does not occure.
May 27th, 2011 4:36am

Although the robocopy documentation does not anticipate every combination of switches (because there are simply too many possibilities), to me, combining the /mir and /m switches is confounding. The /mir switch instructs robocopy to create a mirror of the source at the destination - and therefore the file selection is 'all files'. The /m switch instructs robocopy to select only those files having the archive bit set, and to reset this bit on those source files. What is the actual file selection when the two are combined? I would love for this combination to actually work, because I see no other way to reset archive bits on the source when creating a mirror, except to follow with an 'attrib' command, which is resource intensive for large arrays. It seems a shortcoming to me that robocopy can't create both a mirror and reset on the same fly.
Free Windows Admin Tool Kit Click here and download it now
July 5th, 2012 10:44am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics