Aug 08 4
Microsoft's Robocopy compromise
Posted by Angus Kidman @ 11:26 5 comments
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.
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.