[whatwg] Using requestFileSystem to setup mounts

[Charles Pritchard]

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);
}

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.

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.

-Charles