On Tue, Dec 13, 2011 at 2:32 PM, Charles Pritchard <ch...@jumis.com> wrote: > On 11/22/2011 8:58 AM, Glenn Maynard wrote: >> >> >> > Each Entry would have a dummy FileSystem object attached to it, >> in order to >> > fill out the Entry.filesystem API, but all it would contain is >> the file >> > itself. >> >> Again I think this could be left to the UA's implementation decision. >> >> >> The main point is just that a FileSystem object will always be available, >> even if the UA is only exposing one file in a directory which contains other >> (inaccessible) files. Most of the time it wouldn't be used, it just avoids >> exceptional cases in the API. (In other words, Entry.filesystem would not >> become nullable.) > > > I'd like to see a means of getting an "anonymous" FileEntry. > http://www.w3.org/TR/file-system-api/ > > The purpose being to convert a File object into a read-only FileEntry object > (with an anonymous FileSystem object). > > Currently, a FileEntry can be converted into a File object, but to turn a > File object into a FileEntry requires a writable FileSystem as well as a few > calls to file writer methods. > It may be easier to use copyTo instead of FileWriter in some cases, and it > may be easier to treat dataTransfer items as FileEntry objects depending on > the application and code paths.
True; this could be a nice convenience feature, as long as it could be made read-only and all path information could be scrubbed. > This is mostly about ease of use for authors working with the file system > api. > > Glenn proposed something like getAsEntry as a fix for <input type="file" > webkitdirectory>, earlier in this thread, but that's not the use case I'm > focused on. > I suspect that it will come in handy, to be able to work with anonymous file > systems in the future. > > In the meantime, it'd make things a bit easier to use copyTo instead of File > Writer when a file or blob is available. > > -Charles > >