Ugly bug in Robocopy - ignoring security on file level

I really like RoboCopy (robust file copy) utility from Microsoft - if you dont know this tool (I would be surprised), it adds tons of features to standart Copy command - and probably the most useful is /MIR (mirror) that creates mirror of source folder.

One of main benefits of mirror is that it is really fast and you can always use it to easily replicate different folders. Problem is that Mir is ignoring NTFS security.

I know, I know, you can use /SEC - but you can still run into issues. Problem is that when using MIR switch, robocopy ignores ACL - so if you use RoboCopy Source Target /MIR /SEC, security settings are transfered - BUT if they are changed on source or target, these ACLs are not mirrored. This is only problem of files, not folders(!).

 This can be really annoying, currently you can use following as workaround:

RoboCopy /Mir <Source> <Target>
RoboCopy /E /Copy:S /IS /IT <Source> <Target>

 Second line will copy files again, but now with security...

 Hope so Microsoft will fix this in next (if any) version of RoboCopy :(

UPDATE: So, there are two newer versions than XP010 - version XP026 (that is part of Robocopy GUI) and XP027 (this is part of Windows Vista). Problem is that XP027 is not working under Windows XP\2003 (not tested, if someone have Vista, please test and let me know). Version XP026 is part of (not really useful - my opinion) Robocopy GUI. You can either install it and get Robocopy from System32... You can then use syntax RoboCopy <Source> <Target> /SecFix /xo /xn /xc /e /COPY:S
This wont copy files, it will just reapply security settings.

 UPDATE2: Due to fact that it is not that easy to get Robocopy XP026 and you must install (quite ugly and useless) GUI to get it, I uploaded it to Microsoft SkyDrive:

Published Mon, Mar 3 2008 20:34 by martin
Filed under: ,

Comments

# re: Ugly bug in Robocopy - ignoring security on file level

XP027(from windows 2008) is not working under xp. I get an error message that it is not a valid win 32 application.

I had the same problem with the acl's. But also noticed that the /mon function does't work for junction folders created with linkd (RK tool).

Tuesday, June 03, 2008 10:14 AM by Arjan de Vries

# re: Ugly bug in Robocopy - ignoring security on file level

Thanks.  I was wondering where that XP026 version came from.  I have the GUI installed, and thought that XP026 must have been added by SP3.

Are you sure that the XP027 Vista version does not work in XP/2003?  I wonder why that is?

Do you know the version number for Vista SP1, and Windows Server 2008?  I do not have them to hand right now.

Friday, June 06, 2008 9:38 AM by Synapse Syndrome

# re: Ugly bug in Robocopy - ignoring security on file level

Nope, it doesn't - there is hardcoded check :( Maybe I will try to create shim to enable it, but I am not sure if it will work or not (shims are using existing options from OS and I don't expect XP have hardcoded fix for "Vista" mode).

Vista SP1 and w2k8 server have same version as far as I know (XP028).

Martin

Friday, June 06, 2008 10:17 AM by martin

# re: Ugly bug in Robocopy - ignoring security on file level

This isn't just a bug with /mir, /copyall is supposed to copy everything including NTFS perms, but under 2008 they are not being replicated

Monday, January 19, 2009 2:08 PM by Terry

# re: Ugly bug in Robocopy - ignoring security on file level

you sir, are a saviour :)

Tuesday, January 20, 2009 10:58 PM by tom

# re: Ugly bug in Robocopy - ignoring security on file level

On a similar but tangent issue, I have a problem with robocopy XP010.

Originally I implemented switches /E /Purge and /COPY:DAT as well as /REG /W:10 /R:10.

I then altered the batch file to run without the /REG /W:10 /R:10.

Everything seemed to be fine. With a bit of experience, I began to realize that all I really needed was the /MIR switch. So, I altered my comand line in the batch file to include only this /MIR switch. But here is the problem:

The Command window, when the batch file executes, still shows that all the original switches I used are active! I added the /LOG:filename switch and sure enough each batch run shows all the original and the added switches as being used in the printout.

As a command line executable, it does not use the registry file in Windows, yet the /REG switch stores the values of W and R somewhere. I am willing to bet that the original set of switches I used on the command line when I also used the /REG switch were also "registered" and now keep on coming back as a bad penny.

Can anyone tell me how I could purge all these switches and be able to run Robocopy with only the /MIR /TEE and /LOG:file switches?

I have been on the Interent chasing this for over 7 hours and am at my wits end...

Thanks very much.

Peter

Friday, February 06, 2009 12:55 AM by Peter

# re: Ugly bug in Robocopy - ignoring security on file level

Hi Peter,

/REG is saving /W and /R entries to registry, so it is used to overwrite default settings (W:30 and R:1000000).

These settings are stored in HKEY_CURRENT_USER\Software\Microsoft\ResKit\Robocopy afterwards:

- R -> RetryMax

- W -> WaitTime

Martin

Saturday, February 07, 2009 4:37 PM by martin

# re: Ugly bug in Robocopy - ignoring security on file level

Thank you for that feedback Martin. It was appreciated.

Peter

Thursday, February 12, 2009 10:57 AM by Peter

# Folder dates and /DCOPY: T and /MOV options

Another problem:

It seems when I specify the MOV option then the folder times are no longer preserved:

robocopy src dest /COPYALL /E /DCOPY:T /MOV

When I use /DCOPY but don't specify the /MOV option then the folder modified dates are preserved.

Friday, February 27, 2009 3:28 PM by User

# re: Ugly bug in Robocopy - ignoring security on file level

koukam, ze M$ nakonec zvolil svuj klasicky styl, ze kdyz uz dotahne nejaky

program skoro k dokonalosti, tak ho zahodi a zacne znova neco noveho ;o((

RoboCopy --> RoboCopy GUI --> RichCopy

technet.microsoft.com/.../2009.04.utilityspotlight.aspx

Friday, April 10, 2009 10:59 AM by VasekB

# re: Ugly bug in Robocopy - ignoring security on file level

Nie je to uplne identicke - RichCopy je async copy, t.j. kopiruje cez viacero vlakien... Mne skor vadi, ze MS pridal RoboCopy do Windows, ale neopravili tam kopec chyb (a nejake nove pribudli) :(

Friday, April 10, 2009 1:36 PM by martin

# re: Ugly bug in Robocopy - ignoring security on file level

Firstly, not checking every file for pure security alterations makes the replication work more quickly. Secondly, Allen argues that most companies are happy with directory level security, and that setting file by file permissions is the kind of fiddly nitpicking most people won't bother with.

Finally, if you do want to replicate on this basis, you can use a chain of commands to ensure that all files altered with security do get changed as part of the replication process. The option is there if you really want it, but as a default behaviour, it wasn't necessary.

Monday, April 20, 2009 8:57 AM by Spundae

# re: Ugly bug in Robocopy - ignoring security on file level

I am having problems too with robocopy not copying permissions in Windows 2008 server, it just randomly does not copy permissions and leaves the folders with default permissions. anyone found a solution to it yet ?

Thursday, July 16, 2009 5:14 AM by Ranj

# @Ranj

solution mentioned in this post should work fine - sync and reapply security

Thursday, July 16, 2009 5:38 AM by Martin Zugec