Add File::Duplicate to duplicate a file handle.

base/files/file.h

Index: base/files/file.h
diff --git a/base/files/file.h b/base/files/file.h
index 7b6366c1c2edaa2c6ccb695f2f075ff83f0d002b..c4bff20bcde7718a45ff34e389e51a8b174d3ffb 100644
--- a/base/files/file.h
+++ b/base/files/file.h
@@ -287,6 +287,10 @@ class BASE_EXPORT File {
   // Unlock a file previously locked.
   Error Unlock();
 
+  // Returns a new handle to this file for use within the current process. On

[rvargas (doing something else), 2015/03/18 20:56:42]

nit: handle -> object

[grt (UTC plus 2), 2015/03/19 03:31:02]

Done.

+  // POSIX, only the original File will obey FLAG_DELETE_ON_CLOSE.

[rvargas (doing something else), 2015/03/18 20:56:42]

I don't think this behavior is posix exclusive... or rather, the comment is kind
of misleading about what happens. How about saying that on posix that flag is
not propagated (if we have to say something here)

[grt (UTC plus 2), 2015/03/18 21:06:24]

I singled out POSIX here because "delete on close" is implemented by base::File
there, whereas on Windows the OS does it and the order of closes doesn't matter:
the deletion takes place when all are gone (at least, this is my understanding).
How does this sound:

Handling of FLAG_DELETE_ON_CLOSE varies by OS. On POSIX, the File object that
was created or initialized with this flag will unlink the underlying file on
close. On Windows, the underlying file is deleted when the last handle to it is
closed.

[rvargas (doing something else), 2015/03/18 21:29:58]

sounds good

[grt (UTC plus 2), 2015/03/19 03:31:02]

Done.

+  File Duplicate();
+
   bool async() const { return async_; }
 
 #if defined(OS_WIN)