Added CopyRegKeyWorkItem in support of IE low rights policy fixes.

chrome/installer/util/registry_key_backup.h

Index: chrome/installer/util/registry_key_backup.h
diff --git a/chrome/installer/util/registry_key_backup.h b/chrome/installer/util/registry_key_backup.h
new file mode 100644
index 0000000000000000000000000000000000000000..b8233dd7e2de99976d136670ecffa6c3f64d0967
--- /dev/null
+++ b/chrome/installer/util/registry_key_backup.h
@@ -0,0 +1,68 @@
+// Copyright (c) 2011 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef CHROME_INSTALLER_UTIL_REGISTRY_KEY_BACKUP_H_
+#define CHROME_INSTALLER_UTIL_REGISTRY_KEY_BACKUP_H_
+#pragma once
+
+#include <windows.h>
+
+#include <algorithm>
+#include <string>
+
+#include "base/basictypes.h"
+#include "base/memory/scoped_ptr.h"
+
+namespace base {
+namespace win {
+class RegKey;
+}  // namespace win
+}  // namespace base
+
+// A container for a registry key, its values, and its subkeys.  We don't use
+// more obvious methods for various reasons:
+// - RegCopyTree isn't supported pre-Vista, so we'd have to do something
+//   different for XP anyway.
+// - SHCopyKey can't copy subkeys into a volatile destination, so we'd have to
+//   worry about polluting the registry.
+// We don't persist security attributes since we only delete keys that we own,
+// and we don't set custom attributes on them anyway.
+class RegistryKeyBackup {
+ public:
+  RegistryKeyBackup();
+  ~RegistryKeyBackup();
+
+  // Recursively reads |key_path| into this instance.  Backing up a non-existent
+  // key is valid.  Returns true if the backup was successful; false otherwise,
+  // in which case the state of this instance is not modified.
+  bool Initialize(HKEY root, const wchar_t* key_path);
+
+  // Writes the contents of this instance into |key|.  The contents of
+  // |key_path| are not modified If this instance is uninitialized or was
+  // initialized from a non-existent key.
+  bool WriteTo(HKEY root, const wchar_t* key_path) const;
+
+  void swap(RegistryKeyBackup& other) {
+    key_data_.swap(other.key_data_);
+  }
+
+ private:
+  class KeyData;
+
+  scoped_ptr<KeyData> key_data_;
+
+  DISALLOW_COPY_AND_ASSIGN(RegistryKeyBackup);
+};
+
+namespace std {

[erikwright (departed), 2011/09/16 18:41:45]

This technically (at least) violates the coding guidelines, although I know that
it is considered appropriate for STL.

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Namesp...

I failed to find any code already doing this:

http://codesearch.google.com/codesearch#search/&exact_package=chromium&q=%22n...

I think it might be best to do without if possible. Given that you defined a
member swap(), is it still required?

I guess the question begs to be asked, is it worth implementing swap over using
scoped_ptr as you previously did? I'm indifferent, I guess, though technically
defining your own implies writing a test case for your own.

[grt (UTC plus 2), 2011/09/16 20:44:46]

The style guide's guidance is overreaching in this case.  This definition into
std is appropriate since it is permitted to specialize templates in std.  C++-08
17.4.3.1: "A program may add template specializations for any
standard library template to namespace std."
It allows callers to use the "standard" way of calling swap, where they don't
need to know or care whether or not the thing being swapped can do it smartly or
not.  Since it's not normal for Chromium, I'll yank it.  (I figured this would
stand out.  :-) )
I think the swap itself is fine.  I'll remove the template specialization since
it isn't required (the caller in this case can invoke the method directly) and
add a unit test.

+
+template<>
+inline void swap<RegistryKeyBackup>(RegistryKeyBackup& a,
+                                    RegistryKeyBackup& b) {
+  a.swap(b);
+}
+
+}  // namespace std
+
+#endif  // CHROME_INSTALLER_UTIL_REGISTRY_KEY_BACKUP_H_