Fix various issues in RedirectToFileResourceHandler.

content/browser/loader/temporary_file_stream.cc

Index: content/browser/loader/temporary_file_stream.cc
diff --git a/content/browser/loader/temporary_file_stream.cc b/content/browser/loader/temporary_file_stream.cc
new file mode 100644
index 0000000000000000000000000000000000000000..7f04f4dc5acbc6f7f61d704409f1c45f83213100
--- /dev/null
+++ b/content/browser/loader/temporary_file_stream.cc
@@ -0,0 +1,61 @@
+// Copyright 2013 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.
+
+#include "content/browser/loader/temporary_file_stream.h"
+
+#include "base/bind.h"
+#include "base/callback.h"
+#include "base/files/file_util_proxy.h"
+#include "base/memory/ref_counted.h"
+#include "content/public/browser/browser_thread.h"
+#include "net/base/file_stream.h"
+#include "webkit/common/blob/shareable_file_reference.h"
+
+using webkit_blob::ShareableFileReference;
+
+namespace content {
+
+namespace {
+
+void DidCreateTemporaryFile(
+    const CreateTemporaryFileStreamCallback& callback,
+    base::File::Error error_code,
+    base::PassPlatformFile file_handle,
+    const base::FilePath& file_path) {
+  DCHECK(BrowserThread::CurrentlyOn(BrowserThread::IO));
+
+  if (error_code != base::File::FILE_OK) {
+    callback.Run(error_code, scoped_ptr<net::FileStream>(), NULL);

[mmenke, 2014/03/03 21:10:11]

The old code seems to have handled deleting the file when there was an error... 
It looks to me like we'll never get an error other than PLATFORM_FILE_OK when we
have a file, on either windows or posix, just calling out this fact i ncase I'm
missing something.

("PassPlatformFile" nominally sounds like it's supposed to delete the file if
not used, but it doesn't actually seem to have any code to actually do this).

[davidben, 2014/03/03 23:20:18]

The old code handled that? It didn't really check if the file was there in the
first place.

That should be handled by this guy: https://codereview.chromium.org/183003009/

[mmenke, 2014/03/04 18:06:52]

The old code actually did handle that,  in a roundabout way.

FileStream handled that:  If we got ok with an invalid file stream, it would
return an error on write, and if we got a valid handle but an error of some
sort, it would return whatever we got when trying to write to the file.

Looking at the underlying code, I don't think either case is possible, but given
the complete absence of function documentation, and the rather odd code to
determine the return code...

+    return;
+  }
+
+  // Cancelled or not, create the deletable_file so the temporary is cleaned up.
+  scoped_refptr<ShareableFileReference> deletable_file =
+      ShareableFileReference::GetOrCreate(
+          file_path,
+          ShareableFileReference::DELETE_ON_FINAL_RELEASE,
+          BrowserThread::GetMessageLoopProxyForThread(
+              BrowserThread::FILE).get());
+
+  scoped_ptr<net::FileStream> file_stream(new net::FileStream(
+      file_handle.ReleaseValue(),
+      base::PLATFORM_FILE_WRITE | base::PLATFORM_FILE_ASYNC,
+      NULL));
+
+  callback.Run(error_code, file_stream.Pass(), deletable_file);
+}
+
+}  // namespace
+
+void CreateTemporaryFileStream(
+    const CreateTemporaryFileStreamCallback& callback) {
+  DCHECK(BrowserThread::CurrentlyOn(BrowserThread::IO));
+
+  base::FileUtilProxy::CreateTemporary(
+      BrowserThread::GetMessageLoopProxyForThread(BrowserThread::FILE).get(),
+      base::PLATFORM_FILE_ASYNC,
+      base::Bind(&DidCreateTemporaryFile, callback));
+}
+
+}  // namespace content