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

[Kinuko Yasuda]

(resending with re-format)
On Thu, Nov 17, 2011 at 3:21 AM, Glenn Maynard <glenn at zewt.org>
wrote:>> 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.>> I don't think
it's possible to do this correctly, because URLs created with> toURL
have no equivalent to revokeObjectURL.  A long-running page has no
way> to avoid "leaking" these references until the page exits.  Adding
a revoke> method for toURL would essentially turn it into
URL.createObjectURL.>> Needing to revoke URLs when dealing with worker
communication also makes it> very hard for users to get it right.  For
example, suppose a Window sends a> toURL-generated URL to a Worker.
How do you ensure that the URL is revoked> after the worker has
received it and finished converting it back to an> Entry?  The Worker
might be killed (eg. due to CPU quotas) at any time,> making avoiding
resource leaks very hard.
I assume filesystem: URLs are like files: URL (but with the origin
info);the actual data resides on-disk and the URL is a locator to
thelocalresource, but not the 'live' reference that controls the
lifetimeofthe resource itself.  Similarly having URLs (or Entry)
doesn't meanthe holder can access the underlying file.  The file could
be removedor moved by other scripts or by anyone in non-sandboxed
cases.
If we apply the current URL model to non-sandboxed cases, passingURLs
wouldn't imply anything about the lifetime (of the data or ofaccess
rights) and the access rights would simply expire when thecontext
where the Entry was created goes away.  This would limitseveral
possible scenarios like the ones you noted but would stillbe
consistent.  (please read on)
> These are just the usual problems with manual resource management, which> should be avoided if at all possible.  We already have a mechanism that> cleanly avoids all of this, with structured clone and File.
Having said that, I'm kinda convinced that structured cloning
mightgive a clean solution and open up more possibilities with
explicit lifetimecontrol and capability passing.(I guess, though, if
we continue thisdiscussion maybe we should split the topic and move
onto public-webapps?)
> 1. Create a file with the name filename + ".new".> 2. Write the new file contents to the file.> 3. Rename filename + ".new" to filename, overwriting the original file.<snip>
> This is complex, though, and leads to new questions, like how long the> mappings last if the underlying file is deleted.  As a data point, note that> most Windows applications are unable to access files whose filenames can't> be represented in the current ANSI codepage.  That is, if you're on a US> English system, you can't access filenames with Japanese in them.  (Unicode> applications can, but tons of applications in Windows aren't Unicode;> Windows has never made it simple to support Unicode.)  If users find that> reasonable, it might not be worth all this for the even rarer case of> illegal codepoints in Linux.
I admit that with write/rename operations such path mappingsolution
could become very complex.  That's why I explicitly noted"if it's for
read-only cases".
> For what it's worth, I think the only sane approach here is an isolated> break from attempting to make everything interoperable, and allow the> platform's limitations to be visible.  (That is, fail file creation if the> path depth or filename length is too long on the platform; succeed with file> creation even if it would fail on a different platform, and so on.)  I think> this is just inherent to allowing this sort of access to real filesystems,> and trying to avoid it just causes other, stranger problems.
For writing cases I agree with this, or simply I cannot think
ofabetter approach.  And if that's the case it might make more
sensetohandle readonly cases in the same way.