Launch packaged app with files on Drive on Chrome OS.

webkit/fileapi/file_system_types.h

Index: webkit/fileapi/file_system_types.h
diff --git a/webkit/fileapi/file_system_types.h b/webkit/fileapi/file_system_types.h
index f657218ea014e4e138a9589554475e2acd9e3dbe..d06fcec972f0d1df5827e69fff0a7772dd9ffbf2 100644
--- a/webkit/fileapi/file_system_types.h
+++ b/webkit/fileapi/file_system_types.h
@@ -75,6 +75,10 @@ enum FileSystemType {
   // Indicates a Syncable sandboxed filesystem which can be backed by a
   // cloud storage service.
   kFileSystemTypeSyncable,
+
+  // Indicates an external filesystem but with file path is specified by
+  // a full path, rather than a relative path from a mount point.
+  kFileSystemTypeExternalFullPath,

[kinuko, 2013/03/19 20:34:50]

This filesystem type is being added not based on underlying implementation but
for higher-level mount point view.  Could we come up with a better name (and
better comment) to indicate the fact?  'ExternalFullPath' sounds too biased to
the chromeos usage to me.  How one can guess this could mean NativeLocal in
non-chromeos world?

The term 'Native' may feel better than 'External', since in ChromeOS 'native
path' might just mean the external filesystem path (I could be wrong). 
kFileSystemTypeNativeForPlatformApp?  May sound too restrictive?

...oh but it's handled in ExternalMountPoints, that's why you prefixed External.
 Maybe should we just use this type only for ChromeOS and remove the special
cracking using NativeLocal for non-chromeos?

[kinaba, 2013/03/21 07:35:13]

Changed to kFileSystemTypeNativeForPlatformApp.

Using the type only for ChromeOS is possible, but it means
the uses of RegisterFileSystemForPath in apps must be wrapped
with #ifdef OS_CHROMEOS, which doesn't seem clean and maintainable.

On 2013/03/19 20:34:50, kinuko wrote:

 };
 
 }  // namespace fileapi