Moving away from shell api to support long path names on windows for filesystem.

webkit/fileapi/file_system_path_manager.cc

Index: webkit/fileapi/file_system_path_manager.cc
===================================================================
--- webkit/fileapi/file_system_path_manager.cc	(revision 68690)
+++ webkit/fileapi/file_system_path_manager.cc	(working copy)
@@ -124,6 +124,7 @@
       DispatchCallbackOnCallerThread(FilePath());
       return;
     }
+
     DispatchCallbackOnCallerThread(root);
   }
 
@@ -170,13 +171,27 @@
   scoped_ptr<FileSystemPathManager::GetRootPathCallback> callback_;
 };
 
+FilePath FileSystemPathManager::GetFileSystemCommonRootDirectory(
+    const FilePath& root_path) {
+#if defined(OS_WIN)
+  // To specify an extended-length path, "\\?\" prefix is used. Else path names
+  // are limited to 260 characters.
+  if (!root_path.StartsWithExtendedPathPrefix()) {

[Erik does not do reviews, 2010/12/16 18:34:54]

I really don't like this approach.  Doesn't this mean we need to sprinkle this
logic around everywhere in our code that manipulates FilePath objects?  It seems
like we should come up with a way to handle this in FilePath.Append where it
magically prepends the prefix when it needs to.

[Mark Mentovai, 2010/12/16 19:48:19]

This is wrong. It should check whether root_path is already a UNC path. Whether
it’s a UNC path in \\?\ or anywhere else is irrelevant.

[Kavita Kanetkar, 2010/12/17 00:59:32]

Isn't it the case that even in UNC if path doesn't begin with \\?\ it will be
restricted to 260? Maybe I don't understand your comment correctly.

On 2010/12/16 19:48:19, Mark Mentovai wrote:

[michaeln, 2010/12/17 01:22:24]

In gears this was handled by doing the \\?\'ification just prior to making win32
system calls instead of trying to make sure that paths were expressed in the
long'ish way throughout.

http://code.google.com/p/gears/source/browse/trunk/gears/base/common/file_win...

[Kavita Kanetkar, 2010/12/23 03:14:28]

Changed this to a central place in FilePath. And made FilePath a bit smarter to
manipulate extended paths and 8.3 format ones.

On 2010/12/16 18:34:54, Erik Kay wrote:

+    FilePath::StringType extended_length_str(FilePath::kExtendedPathPrefix);
+    extended_length_str.append(root_path.value());
+    return FilePath(extended_length_str).Append(kFileSystemDirectory);

[Mark Mentovai, 2010/12/16 19:48:19]

Nobody takes care to do this anywhere else in Chrome as far as I’m aware. I
think we’re generally expecting that if people are working with
tremendously-long paths, they’ll need to come at us in UNC format anyway.
They’ll need to come at many other programs in that format as well.

What’s special about this case?

[Kavita Kanetkar, 2010/12/17 00:59:32]

Yes. Actually shell32 api that restricts path lengths to 260 is used in many
places. The fix for allowing extended path lengths with filesystem was a
priority because the profile directory and the filesystem root path was already
too long. Hence user-created files/directories need extended path support.

On 2010/12/16 19:48:19, Mark Mentovai wrote:

+  }
+#endif
+  return root_path.Append(kFileSystemDirectory);
+}
+
 FileSystemPathManager::FileSystemPathManager(
     scoped_refptr<base::MessageLoopProxy> file_message_loop,
     const FilePath& profile_path,
     bool is_incognito,
     bool allow_file_access_from_files)
     : file_message_loop_(file_message_loop),
-      base_path_(profile_path.Append(kFileSystemDirectory)),
+      base_path_(GetFileSystemCommonRootDirectory(profile_path)),
       is_incognito_(is_incognito),
       allow_file_access_from_files_(allow_file_access_from_files) {
 }
@@ -215,7 +230,8 @@
   DCHECK(!type_string.empty());
 
   FilePath origin_base_path = base_path_.AppendASCII(storage_identifier)
-                                        .AppendASCII(type_string);
+      .AppendASCII(type_string);
+
   std::string name = storage_identifier + ":" + type_string;
 
   scoped_refptr<GetFileSystemRootPathTask> task(