gdata: Fix "save as pdf" to work on Google Drive.

chrome/browser/chromeos/gdata/gdata_file_system_interface.h

Index: chrome/browser/chromeos/gdata/gdata_file_system_interface.h
diff --git a/chrome/browser/chromeos/gdata/gdata_file_system_interface.h b/chrome/browser/chromeos/gdata/gdata_file_system_interface.h
index 7b01766cff3d19802af058680991f88577a31d68..7cd231f24af9a23a792aeacce4310476b06336b2 100644
--- a/chrome/browser/chromeos/gdata/gdata_file_system_interface.h
+++ b/chrome/browser/chromeos/gdata/gdata_file_system_interface.h
@@ -178,6 +178,13 @@ class GDataFileSystemInterface {
   virtual void CloseFile(const FilePath& file_path,
                          const FileOperationCallback& callback) = 0;
 
+  // Calls OpenFile, |callback|, then CloseFile in this order.
+  //
+  // Can be called from UI/IO thread. |callback| is run on th blocking thread
+  // pool that allows file operations.
+  virtual void PrepareWritableFileAndRun(const FilePath& path,
+                                         const OpenFileCallback& callback) = 0;

[satorux1, 2012/07/27 22:56:29]

We want to minimize functions in GDataFileSystem. Can you implement this outside
of GDataFileSystem?

Besides, please write a unit test for the new function.

[kinaba, 2012/07/28 00:06:10]

I'll think about it. Do you have any advice where it would be the better place
to put it?
I currently chose to place it inside GDataFileSystem for safely getting (or not
getting, when already destructed) pointer to it for calling CloseFile().

[satorux1, 2012/07/28 00:44:07]

I guess we can move this to gdata_util.cc. For CloseFile(), we should probably
check if GDataSystemService::file_system() is non-null before calling it. I'm
not sure if it's feasible, though.

You might also want to make it a class and put into new files. gdata_util.cc is
also getting bigger. :P

[kinaba, 2012/08/01 13:48:45]

Created a separate class (suggestions are highly welcome for
the name of the class!) and made it to be owned by GDataSystemService.

The reason is, we need to call GDataFileSystem::CloseFile() after
|callback| executed its task on FILE thread, during which, not only
GDataFileSystemInterface but also GDataSystemService and Profile might
have gone (if I understand the lifetime of Profile correctly).
I thought the most handy way to detect this destruction is having a
weak_ptr to an instance (in)directly owned by Profile.

Let me know if there's a better approach.

+
   // Copies |src_file_path| to |dest_file_path| on the file system.
   // |src_file_path| can be a hosted document (see limitations below).
   // |dest_file_path| is expected to be of the same type of |src_file_path|