My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 63574: FileSystem API paths are too short at 100 bytes -- increase to 255 bytes
11 people starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  ericu@chromium.org
Closed:  May 2011
Cc:  ericu@chromium.org, kinuko@chromium.org, micha...@chromium.org, kkanet...@chromium.org, adamk@chromium.org

Blocking:
issue 32277

Restricted
  • Only users with Commit permission may comment.


Sign in to add a comment
 
Reported by downch...@gmail.com, Nov 17, 2010
Chrome Version       : 9.0.576.0

Currently, the implementation of the FileSystem API restricts total path length, filename included, to 100 bytes.

Attempting to get a file with a total path + filename length of over 100 bytes results in a state error: FileError code 7: INVALID_STATE_ERR .

entry.getFile('100 Bytes or More.', ... );
direntry.getFile('100 bytes - path length + 1', ...);

This is clearly intentional, but the length is far too short. Current discussion suggests a 255 segment limit, and a 4095 byte total path limit. 
http://www.w3.org/TR/file-system-api/#uniformity-of-interface

At the very least -- bump the limit up to 255 bytes. 100 is too short for long filenames held within subdirectories.
Nov 18, 2010
#1 peter@chromium.org
(No comment was entered for this change.)
Status: Untriaged
Cc: er...@chromium.org
Labels: -Area-Undefined Area-WebKit WebKit-WebApps
Nov 18, 2010
#2 kinuko@chromium.org
I guess the total path length (including sandbox dir) is hitting Windows MAX_PATH limitation.
(100 shouldn't be an intentional limit)
Cc: kin...@chromium.org
Labels: OS-Windows
Nov 18, 2010
#3 ericu@chromium.org
If this is happening on Windows, we just need to switch over to the extended path convention: http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath.  When we fix this, we should also add in the actual segment and path limits from the spec if we haven't already.
Nov 18, 2010
#4 downch...@gmail.com
You're correct: it's windows, and it is the MAX_PATH limitation of 256 chars. I have an 8 char user name -- it's 162 characters just to reach the temp file system. Is this something we can get fixed in M9?

Without a fix, I'll have to check my path length by brute-force to figure out how long the path is to the temporary/perm directory.

Nov 18, 2010
#5 kinuko@chromium.org
@kavita kindly volunteered to take a look at this.

Kavita, the problem can be easily tested by trying to create a file with a long path.  Probably we can add a windows specific helper method to FilePath class that prepend '//?/' to the path.
It'd be nice to add a test in file_system_operation_unittest for this one.
Owner: kkanet...@chromium.org
Nov 18, 2010
#6 kinuko@chromium.org
Sorry, '//?/' -> '\\?\' was the correct prefix.  (We should make sure if it's safe to always specify it.)

@kavita: as for implementation we could return the prefixed root path from FileSystemPathManager::GetFileSystemRootPath (maybe in GetFileSystemRootPathTask::DispatchCallback).
Nov 23, 2010
#7 ka...@chromium.org
(No comment was entered for this change.)
Labels: Mstone-10
Nov 26, 2010
#10 downch...@gmail.com
You may want to file this bug with WebKit upstream, as a place to submit a patch for bug review. Here's the general WebKit FileSystem API bug list:

https://bugs.webkit.org/show_bug.cgi?id=42903
Nov 30, 2010
#11 kinuko@chromium.org
Hmm this is bad, we use MAX_PATH size array when we call SHFileOperation (for some Copy and Delete cases in file_util_win).  What's worse SHFileOperation doesn't seem to accept '\\?\' prefixed paths.  I'm afraid we need to revert the change for now.
Status: Assigned
Nov 30, 2010
#12 bugdroid1@gmail.com
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=67703

------------------------------------------------------------------------
r67703 | kinuko@chromium.org | Tue Nov 30 02:25:53 PST 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/fileapi/file_system_path_manager_unittest.cc?r1=67703&r2=67702&pathrev=67703
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/fileapi/file_system_path_manager.cc?r1=67703&r2=67702&pathrev=67703
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/fileapi/file_system_path_manager.h?r1=67703&r2=67702&pathrev=67703
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/browser_render_process_host.cc?r1=67703&r2=67702&pathrev=67703
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/fileapi/file_system_operation_unittest.cc?r1=67703&r2=67702&pathrev=67703

Revert 67385 - On windows filepaths need \\?\ prefix to allow extended file path names. Fix to  bug 63574 .

Turned out that we need more changes to make extended paths work.

BUG=63574
TEST=file_system_operation_unittest.cc and manually tested on FAT32.


Review URL: http://codereview.chromium.org/5259003

TBR=kkanetkar@chromium.org
Review URL: http://codereview.chromium.org/5357009
------------------------------------------------------------------------
Nov 30, 2010
#13 downch...@gmail.com
SHFileOperation may lead to some strange errors in Windows Vista. IFileOperation is an intended replacement... Looking into what to do about XP and prior, re: '\\?\' prefix.
Nov 30, 2010
#14 downch...@gmail.com
This is above my head: have you tried the other operations: "SHFileOperationW (Unicode) and SHFileOperationA (ANSI)"
http://msdn.microsoft.com/en-us/library/bb762164(VS.85).aspx

The Unicode variant should support what we're trying to accomplish. It wouldn't need the '\\?\' prefix. And it'd be a superior solution to doing FileOperations that don't support unicode/long file paths. If that's not the fix... we'll keep looking.
Nov 30, 2010
#15 downch...@gmail.com
Well it might need the prefix, but regardless, it makes more sense than the bare SHFileOperation.
Nov 30, 2010
#16 kinuko@chromium.org
(No comment was entered for this change.)
Labels: Feature-FileSystem
Dec 8, 2010
#17 downch...@gmail.com
What's the status on giving this another run?
Dec 8, 2010
#18 kkanet...@google.com
Final few things left to test/submit.
Dec 9, 2010
#19 kerz@chromium.org
P2 bugs with an owner that are not marked as started are being automatically moved to mstone:11.
Labels: -Mstone-10 MovedFrom-10 Mstone-11
Dec 15, 2010
#20 downch...@gmail.com
On track for M10?
Dec 15, 2010
#21 kkanet...@google.com
yes. code in review.
Jan 31, 2011
#22 downch...@gmail.com
Checking in with you. Looks like the review is stalled:
http://codereview.chromium.org/5754002/
Jan 31, 2011
#23 ericu@google.com
It's out of M10, but we'll get to it soon.
Feb 16, 2011
#24 micha...@chromium.org
we have to find a new owner for this
Owner: ---
Cc: micha...@chromium.org kkanet...@chromium.org ad...@chromium.org
Feb 16, 2011
#25 ian.chromium@gmail.com
(No comment was entered for this change.)
Owner: ad...@chromium.org
Feb 16, 2011
#26 downch...@gmail.com
Ian Fette has suggested that the filesystem API will use a virtual file system, getting around these issues. This is a very different usage profile -- applications like Picasa and iPhoto will not be able to interact.
Feb 28, 2011
#27 adamk@chromium.org
Removing from Mstone-11 as the DB-based re-implementation of file paths will take more than a week to implement.
Labels: -MovedFrom-10 -Mstone-11 Mstone-X
Apr 27, 2011
#28 adamk@chromium.org
(No comment was entered for this change.)
Owner: ericu@chromium.org
May 28, 2011
#29 ericu@chromium.org
Fixed by the obfuscated filesystem,
Status: Fixed
Oct 12, 2012
#30 bugdro...@chromium.org
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Labels: Restrict-AddIssueComment-Commit
Blocking: -chromium:32277 chromium:32277
Mar 10, 2013
#31 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Area-WebKit -WebKit-WebApps Cr-Content-WebApps Cr-Content
Apr 5, 2013
#32 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Cr-Content Cr-Blink
Sign in to add a comment

Powered by Google Project Hosting