Re: file-system-api: filename restrictions

On 1/11/2011 2:33 PM, Eric Uhrhane wrote:
> Actually, it's not just that Linux users now have to worry about
> Windows rules; Windows users also have to worry about Linux rules, in
> particular the path length limitation, which is 255 bytes on Linux but
> 255 UTF-16 code points on Windows.

WebKit is addressing the current issue in active releases (a 255 byte 
path length limit):
http://code.google.com/p/chromium/issues/detail?id=63574

Those very-short length limitations are really frustrating.


>> It's also a pain for backing up files, eg. copying "moon rock?.jpg" to
>> "moon rock?.jpg~", and for "safe writes", writing to "moon
>> rock?.jpg.new" and then renaming the finished file over the original.
>
> I'm looking into the encoding problems now, and will respond later.
> In general we should be able to read any such file already, at the
> very least by enumerating the directory to get the FileEntry, but
> creating files with valid names may be tricky.
A lot of these use cases really would be better served by IndexedDB.
No issues with naming, no issues with file counts/inodes, performance, etc.

Blobs can be stashed nicely, and so forth.

> However, an obvious expansion of this API which we've talked a lot
> about is the ability to expose other "mount points" to the browser.
> For example, a trusted app might be granted access to "My Photos" or
> another similar directory.  There the majority of the files are
> expected to be created by apps outside of the browser, and you run
> into the thumbnail problem you describe above, where a
> read-modify-write of a path or even a copy operation can inadvertently
> create a file path that's banned by the API, but is legal on the host
> system.
>
The <input type="file" webkitdirectory> experiment has opened up some room
for the idea of mount points. Perhaps, further exploration there would 
be helpful.

Received on Wednesday, 12 January 2011 23:38:02 UTC