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

On Wed, Nov 16, 2011 at 2: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.

The unsandboxed storage and actual data doesn't belong to origin, but
the 'origin-specific' concept can be applied to the filesystem
namespace.

I haven't thought about workers cases deeply yet, but am thinking that
we should prohibit access to the dropped folders from the other pages
than the one that received the drop event.  As for the entry URLs I'm
planning to make the URLs to the dropped entries and the filesystem
namespace (that only contains the dropped files) expire when the page
goes away, hoping this would largely simplify the lifetime and
security issues.

> 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).

How do they appear in File.name in existing .files approach?

A naive solution in filesystem approach would be silently ignoring
such files (probably bad) or having in-memory path mapping (would be
slightly better).  For limited read-only drag-and-drop cases we
wouldn't need to think about remapping and the mapping could just go
away when the page goes away, so hopefully implementing such mapping
wouldn't be that hard.

> 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, writing side would have tougher issues, and that's why I started
this proposal only with read-only scenarios.  (I agree that it'd be
good to give another thought about unsandboxed writing cases though)

> --
> Glenn Maynard
>
>

Received on Wednesday, 16 November 2011 06:59:31 UTC