[whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry

[Eric U]

On Tue, Nov 15, 2011 at 9:16 PM, Glenn Maynard <glenn at zewt.org> wrote:
> On Tue, Nov 15, 2011 at 10:58 PM, Kinuko Yasuda <kinuko at chromium.org> wrote:
>>
>> Good point, we could do this synchronously in workers!
>> I think we already have one way to convert Entry to EntrySync:
>> we can get a URL from Entry (Entry.toURL()), send the URL to
>> the worker and get the EntrySync via resolveLocalFileSystemSyncURL.
>>
>> http://www.w3.org/TR/file-system-api/#widl-Entry-toURL
>
> That might be tricky, since toURL looks designed with origin-specific
> sandboxed storage in mind.  Files and directories supplied in this way is
> outside of the sandbox; that makes securely creating persistent, un-expiring
> URLs for arbitrary files a lot harder.
>
> Note that there's another (unrelated) issue: there are unsolved issues with
> filenames when giving access to unsandboxed storage.  They're not
> unsolvable, they've just been punted on so far.  It's been worked around so
> far by splitting apart the rules for sandboxed filesystems from those for
> unsandboxed filesystems, so sandboxed filesystems (those that don't actually
> store filenames on real files) can use simple, interoperable rules that
> wouldn't work for unsandboxed access to real files.
>
> Off-hand, the main issue that directly affects reading is that most
> non-Windows filesystems can store filenames which can't be represented by a
> DOMString, such as invalid codepoints (most commonly mismatched encodings).
> There are more issues with writing: each platform has its own length
> limitations on both filenames and full path lengths; they're not always even
> in the same units, with Linux in bytes and Windows in UTF-16 codepoints; and
> Windows filenames are case-folding (in practice).
>
> The writing issues might be ignorable to implement reading, but they're all
> related issues so it's probably good to try to look at them as a whole.
> (+CC Eric)

Yup; I'm paying attention to those issues.  In previous drafts of the
spec, we handled reading of awkward paths [barring some handling of
invalid code points, where one could enumerate/read files, but perhaps
not really read their exact names], but restricted writing.  I expect
we'll do something similar when we get around to the write cases.  We
can either restrict path creation to what's valid UTF-8, or we could
allow users to try to create arbitrary paths using ArrayBuffers of
bytes.  At any rate, I don't think we're doing anything here that
would limit our options in the future.

> --
> Glenn Maynard
>
>