Blog: Robocopy

I have been working with a customer on a file server and domain migration project. The original plan was to move the files to our Aspire datacenter on a server that was in a different domain. Since we were moving domains, we were going to have to recreate the file permissions on the new domain. I typically run Robocopy using the /COPYALL (which is equivalent to /COPY:DATSOU) parameter, but since we did not want to copy the security, owner, or auditing information, I used /COPY:DAT.
After the initial seeding, the customer prioritized some other moves and postponed the file server migration. During that time, the old datacenter suffered a three day Internet outage. After the outage, the customer decided to move the files while client machines remained on the old domain to prevent another outage. This caused us to need to copy the existing permissions instead of the original plan to translate the permissions at the time of migration.
I changed my Robocopy scripts to use /COPYALL instead of /COPY:DAT. Robocopy copied the permissions for the files that had changed or been added since the seeding, but it did not fix the security permissions for the files that had not changed. This is by design as Robocopy only copies permissions when it copies a file. In order to reevaluate the permissions, the /SECFIX parameter must be added. I changed my script to include /COPYALL /SECFIX and it sync the files AND the permissions. This Robocopy takes longer because it has to evaluate security instead of just the files.
To keep files and permissions in sync, you need to use the /COPYALL and /SECFIX. You can add /v for verbose logging. The Robocopy command I used to keep the files and permissions in sync was: "robocopy source destination /COPYALL /SECFIX /MIR  /S /E /DCOPY:T /R:0 /W:0 /LOG+:log.log".


Robocopy that ships with Windows 7/2008 seems to have a bug. If you specify /MT (for multiple threads), it forces /E (copy empty directories).  This causes it to run much more slowly.  Even if all the destination directories have already been created, it still accesses each one.  If copying over a relatively slow connection,  it can be very slow if you use /MT. [more]

Some discussion is here:


I came across a problem in one of our automated Robocopy command scripts when copying files from NTFS to EMC Celerra file system.  The problem was that every time Robocopy was told to copy files to the EMC Celerra over the VPN, the files were always detected as “newer” on from the originating source.  This caused Robocopy to copy every single file from our network to the remote network each and every time. 

I came across a command line switch for Robocopy: /FFT : Assume FAT File Times (2-second date/time granularity).  So what this does is force Robocopy to use FAT style time stamps which are 2-second granularity.  It allows enough flexibility to account for the way the time is recorded when doing a file copy from NTFS to another file system. This is needed when going between and NTFS and Linux/Unix/FAT or emulated file system.