- From: Glenn Maynard <glenn@zewt.org>
- Date: Wed, 16 Nov 2011 00:16:54 -0500
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
Received on Tuesday, 15 November 2011 21:16:54 UTC