Fix filesystem API file_handlers to work for drive on ChromeOS.

webkit/fileapi/file_system_url.h

 // Copyright (c) 2012 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 WEBKIT_FILEAPI_FILE_SYSTEM_URL_H_
 #define WEBKIT_FILEAPI_FILE_SYSTEM_URL_H_
 
 #include <set>
 #include <string>
 
@@ skipping 102 matching lines @@
   // See the class comment for details.
   const std::string& filesystem_id() const { return filesystem_id_; }
 
   FileSystemType mount_type() const { return mount_type_; }
 
   std::string DebugString() const;
 
   // Returns true if this URL is a strict parent of the |child|.
   bool IsParent(const FileSystemURL& child) const;
 
+  // Returns URL to be used in file system operations. In general the returned
+  // URL is the same as |this|. The exceptions are FileSystemURLs that are build
+  // on top of other FileSystemURLs (e.g. Isolated urls on ChromeOS are build on
+  // top of External urls). In this case the underlying FileSystemURL is
+  // returned.
+  //
+  // Note that the underlying url is determined recursively.
+  FileSystemURL GetForOperations() const;
+
   bool operator==(const FileSystemURL& that) const;
 
   struct WEBKIT_STORAGE_EXPORT Comparator {
     bool operator() (const FileSystemURL& lhs, const FileSystemURL& rhs) const;
   };
 
  private:
   friend class FileSystemContext;
   friend class ExternalMountPoints;
   friend class IsolatedContext;
 
   explicit FileSystemURL(const GURL& filesystem_url);
   FileSystemURL(const GURL& origin,
                 FileSystemType mount_type,
                 const base::FilePath& virtual_path);
   // Creates a cracked FileSystemURL.
   FileSystemURL(const GURL& origin,
                 FileSystemType mount_type,
                 const base::FilePath& virtual_path,
                 const std::string& filesystem_id,
                 FileSystemType cracked_type,
                 const base::FilePath& cracked_path);
 
+  // Sets parameters for the underlying file system URL (the one that will be
+  // returned by |GetForOperations|) that differ from |this|.
+  void SetUnderlyingURL(const FileSystemURL& underlying_url);
+
   bool is_valid_;
 
   GURL origin_;
   FileSystemType type_;
   FileSystemType mount_type_;
   base::FilePath path_;
 
   // Values specific to cracked URLs.
   std::string filesystem_id_;
   base::FilePath virtual_path_;
 
+  // Parameters for the underlying file system URL that are different from this
+  // URL.
+  bool has_underlying_url_;
+  std::string underlying_filesystem_id_;
+  FileSystemType underlying_type_;
+  base::FilePath underlying_virtual_path_;

[kinuko, 2013/03/15 06:54:39]

Hmm, do we need all these additional params? If so I feel something must be
wrong...

[tonibarzic, 2013/03/15 07:36:57]

we could do without underlaying virtual path, and use virtual_path_ url
(actually, we probably should use that path, as it represents part of the
original url). but, file system operations should be changed to use only path()
when using the file.

also, instead of has_underlying_url_ == true we could use underlying_type_ !=
kFileSystemTypeUnknown

[kinuko, 2013/03/17 21:39:09]

So are these changes basically for not changing the existing implementation
(which relies on virtual_path) for now?   If so how about if we make a quick fix
like this:
https://codereview.chromium.org/12483010/

The fact that internal implementation requires its special virtual path is not
necessarily an issue of File API layer, and if that's the only problem a simple
implementation-specific conversion like above seems to work. (Pls correct me if
I'm still missing something)

 };
 
 typedef std::set<FileSystemURL, FileSystemURL::Comparator> FileSystemURLSet;
 
 }  // namespace fileapi
 
 #endif  // WEBKIT_FILEAPI_FILE_SYSTEM_URL_H_