[whatwg] Using requestFileSystem to setup mounts

Hi, thanks for your comment!

On Sun, Nov 20, 2011 at 5:54 AM, Charles Pritchard <chuck at jumis.com> wrote:
> Kinuko Yasuda, I saw your post to whatwg regarding drag-and-drop directory
> mounts.
>
> I'm sure you've seen the various concerns people have with the proposal..
> Like others, I'm also concerned about the security implications of
> traversing a directory and sealing the action upon drop, or otherwise
> setting up a mount point.
>
> That said, directory is still an extension and open to change:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-April/025764.html
> http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#file-upload-state
>
> I'd like to consider your proposal in light of the existing
> requestFileSystem method.
>
> requestFileSystem is still very much open and under experiment with
> Chromium.
>
> For example:
> // Typical use of rFS:
> window.requestFileSystem(window.PERSISTENT, 1*1024*1024, cb);
>
> // Proposal, using DataTransfer with rFS:
> input.ondrop = function(e) {
> ?window.requestFileSystem(e.dataTransfer, 0, cb);
> }

This looks neat, though this would do almost same as what I was
assuming the internal implementation would do.  One clear benefit
I found in your proposal is the code would make the fact that the UA
is actually instantiating a new filesystem per drop clearer.
On the other hand I'm afraid this may slightly complicate the API
by overloading the requestFileSystem.

> There's some slight room for delaying the population of
> e.dataTransfer.files, by using a long-running for loop, or something of that
> sort.  Otherwise,
> if rFS is used, .files will not be populated. This avoids directory
> traversal overhead while using rFS for permissions management.

I may not be quite following this point.  I might be missing
something but isn't it same with the case where the app script
just checks the existence of the new field like .entries and then
falls back to .files if the field doesn't exist?
If .entries is supported the script doesn't need to touch the
.files field thus the UA does not need to populate the .files
field (though I guess if the UA supports .files field it'd start
populating the field before it is actually accessed).

> Authors can pass in "0" for the requested size to give the UA a hint that
> they have no intention of writing to disk.
> This gives authors a chance to use FileEntry instead of File, in addition to
> mounting directories which helps with copyTo.
>
> Might add a new constant, where we have window.PERSISTENT, we could add
> window.MOUNT or EXTERNAL.
>
> That way, I can run: ? if(window.MOUNT) to detect the feature, and otherwise
> fall back to .files.
>
> Additionally, I might pass window.MOUNT into rFS, which may prompt the user
> to select a mount point, bypassing<input> ?altogether.

This sounds cool, and I think eventually we want to have some explicit way
to mount an arbitrary directory in a way this (requestFileSystem(MOUNT)),
but what concerns me most in this generalized API is how we should
define the lifetime of the mount'ed filesystem.

In the original thread I proposed the mounting feature in a very limited
context, i.e. <input> and drag-and-drop context, mainly because I hoped
limiting the scoped and usage would have much smaller security and lifetime
issues (though it still needs a serious consideration).
In the drag-and-drop context it's clear that the permission and namespace
must go away once the context goes away.  But for more generic and
extended usage (I assume requestFileSystem(window.MOUNT) would
imply more generic usage) probably we should be more careful about how
long and when the filesystem lifetime should expire.  Maybe we could collect
real usage with the limited mount support and then move things forward
incrementally.  Wdyt?

> -Charles
>
>

Received on Monday, 21 November 2011 06:10:08 UTC