Microsoft's Robocopy compromise

Microsoft's Robocopy compromise

Summary: Trying to understand the logic behind Microsoft's development decisions is a bit like S&M: it's a painful activity probably best left to others. But a recent example from the storage world does suggest something about Microsoft's "people will beat up on us regardless" dilemma.


Trying to understand the logic behind Microsoft's development decisions is a bit like S&M: it's a painful activity probably best left to others. But a recent example from the storage world does suggest something about Microsoft's "people will beat up on us regardless" dilemma.

In a posting on the Microsoft storage team blog, engineer Kevin Allen discusses an apparent bug in the Robocopy folder replication utility included in the Windows Resource Kit for Windows Server 2003 and XP and then added as a standard feature to Vista and Windows Server 2008. (Sadly for techno-fetishists, the robo part stands for "robust" rather than "robot".)

(Credit: GiniMiniGi)

When replicating information, the original Robocopy will mirror any files that have changed their content, but won't replicate files which have had their security permissions changed but are otherwise unaltered. That might look like a flaw, but according to Allen, who wrote the basic software more than a decade ago, "this behaviour is by design". While that kind of phrasing is sometimes an after-the-fact justification for a product design which deserves punishment, in this case Allen makes a pretty compelling argument.

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.

Of course, one thing Allen probably couldn't have anticipated was that Bill Gates' "security before all else" dictum for Vista would eventually mean that aspect of Robocopy's behaviour would have to be changed, no matter how much it slowed things down. (The fact that Microsoft is still promoting User Account Control as a good idea shows how doggedly it has clung to that view, but I digress.)

Hence in the Vista and 2008 versions of Robocopy, there's an option to ensure security changes are replicated by using the SECFIX switch on the command line. This isn't a bad compromise: the default command still has reasonable performance, but there's an option for people who regularly find themselves messing with security settings for whatever reason.

The downside of this approach is that it means Robocopy doesn't behave consistently between different platforms, and scripts written to run on Vista systems won't make any sense on older machines.

In the Microsoft purist world view, that wouldn't matter, because you'd have Vista and 2008 running everywhere. In real-world heterogeneous environments, it's just another potential source of pain. Maybe storage administrators do need a slightly masochistic streak after all.

Topics: Security, Microsoft, Windows

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion

    If you go back to the pre2003/xp versions of Robocopy you will find that /secfix was available.
    So they removed it and then reinstated it.
  • Say what?

    Why would you write a script to run across multiple platforms and not test it on each platform (at least to OS granularities)?

    Now Microsoft are getting chastised for ADDING features? Now we're stretching the Microsoft bashing a little aren’t we?
  • We need to hold people to calling 'bugs' as bugs

    I recently posted to the Ubuntu Nautilus bug reporting team that while Ubuntu 8.04 is great, when you copy files to/from an NTFS volume, the program re-sets the file date/time to current date/time. The coordinator had the hide to advise by group mail that this was "a design decision" then someone popped up and said "No, it worked properly in the prior version". Whenever people give their specious arguments for how you could consider a 'fault' as anything other than a bug, we need to hold them to the idea that, call it what you will, it is still a fault.
    Part of M$ problem with having software work on multiple platforms is that, because each time they start off on the premise of designing an OS from scratch, nothing really works well over multiple platforms. In that sense it is a bit like US/UK/Oz car design, where after a very successful model, a car manufacturer's designers want a "whole new model" so they design from scratch, and the first few years of the new model have a different set of infuriating new bugs. The Jap way of car design is to always just do incremental improvement, and you hardly ever see new infuriating bugs in their cars. In a similar way, I believe the Open Source model will eventually conquor the M$ way... as much because people don't want to be suffled along to a new OS just because the supplier wants that... better to have gradual updates that keep the system live, rather than letting older systems get intentionally out-of-date in the hope of selling a whole new package.
  • robocopy & secfix

    Is it a bug?
    I have been using ROBOCOPY for a long while for data administration, from local PC copy to multi-terabyte data migration. This is the best data copying and migration of its kind, surpassing specialised tools which cost thousands of $.
    It is my experience that copying the full security information of file and folders adds considerably to replication times (both comparing the source and destination and the actual copying). This behaviour is not a bug, it has been well documented and the ability to choose is a real advantage in some cases. In cases of frequent and large volume replications the ability to choose between replicating data only or both data and security info makes very significant difference.
    In the XP version of ROBOCOPY the “SECFIX” switch was replaced by the “IS” switch. It seems that, like Coca-Cola, Microsoft has bowed to popular demand and retuned the “SECFIX” switch. It is quite easy to tailor a script to the version. E.g. a batch file can be something like this:

    VER | findstr /c:"5.0." > nul

    VER | findstr /c:"5.1." > nul

    VER | findstr /c:"5.2." > nul

    VER | findstr /c:"6.0." > nul

    . . .

    robocopy.exe … /% SCFXOPTN%
  • Reckon that's bad?

    Well you obviously haven't used linux where numerous non standardised shells run a variety of similar commands with similar switches. I say similar because there's no standard for each flavour of linux and the shells they may run and the commands they make available. Complaining about the small issue in robocopy seems trivial. Getting a life may fix the problem.
  • Tired of robocopy moved onto gscopypro

    We had similar situations and robocopy started to be like coding where you had to type arguments you needed to get it working. We did have two other needs that robocopy could not do:
    1) copy open files.
    2) copy the same date and time folder to the target just like the source.

    We found a tool called gscopypro which did all of these and permissions with no issues. Worked on 2003 x64 all the way to windows 2012.

    I highly recommend if you are looking to migrate data or keep data in sync between servers. It is very cheap. here is the link if not outdated.
  • Why Not Long Path Tool

    Long Path Tool can simplify and probably end your problems in unlocking, managing and renaming files that appear to have a long filename.