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

[Glenn Maynard]

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)

-- 
Glenn Maynard