My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
  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
Closed:  May 2011

issue 32277

  • Only users with Commit permission may comment.

Sign in to add a comment
Reported by, 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.

At the very least -- bump the limit up to 255 bytes. 100 is too short for long filenames held within subdirectories.
Nov 18, 2010
(No comment was entered for this change.)
Status: Untriaged
Labels: -Area-Undefined Area-WebKit WebKit-WebApps
Nov 18, 2010
I guess the total path length (including sandbox dir) is hitting Windows MAX_PATH limitation.
(100 shouldn't be an intentional limit)
Labels: OS-Windows
Nov 18, 2010
If this is happening on Windows, we just need to switch over to the extended path convention:  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
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
@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.
Nov 18, 2010
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
(No comment was entered for this change.)
Labels: Mstone-10
Nov 26, 2010
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:
Nov 30, 2010
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
The following revision refers to this bug:

r67703 | | Tue Nov 30 02:25:53 PST 2010

Changed paths:

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 and manually tested on FAT32.

Review URL:
Review URL:
Nov 30, 2010
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
This is above my head: have you tried the other operations: "SHFileOperationW (Unicode) and SHFileOperationA (ANSI)"

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
Well it might need the prefix, but regardless, it makes more sense than the bare SHFileOperation.
Nov 30, 2010
(No comment was entered for this change.)
Labels: Feature-FileSystem
Dec 8, 2010
What's the status on giving this another run?
Dec 8, 2010
Final few things left to test/submit.
Dec 9, 2010
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
On track for M10?
Dec 15, 2010
yes. code in review.
Jan 31, 2011
Checking in with you. Looks like the review is stalled:
Jan 31, 2011
It's out of M10, but we'll get to it soon.
Feb 16, 2011
we have to find a new owner for this
Owner: ---
Feb 16, 2011
(No comment was entered for this change.)
Feb 16, 2011
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
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
(No comment was entered for this change.)
May 28, 2011
Fixed by the obfuscated filesystem,
Status: Fixed
Oct 12, 2012
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
(No comment was entered for this change.)
Labels: -Area-WebKit -WebKit-WebApps Cr-Content-WebApps Cr-Content
Apr 5, 2013
(No comment was entered for this change.)
Labels: -Cr-Content Cr-Blink
Sign in to add a comment

Powered by Google Project Hosting