Re: File modification

On 1/11/2012 12:27 PM, Eric U wrote:
> On Wed, Jan 11, 2012 at 12:22 PM, Charles Pritchard<chuck@jumis.com>  wrote:
>> On 1/11/2012 9:00 AM, Glenn Maynard wrote:
>>>
>>> This isn't properly specced anywhere and may be impossible to implement
>>> perfectly, but previous discussions indicated that Chrome, at least, wanted
>>> File objects loaded from input elements to only represent access for the
>>> file as it is when the user opened it.  That is, the File is immutable (like
>>> a Blob), and if the underlying OS file changes (thus making the original
>>> data no longer available), attempting to read the File would fail.  (This
>>> was in the context of storing File in structured clone persistent storage,
>>> like IndexedDB.)
>>>
>> Mozilla seems to only take a snapshot when the user opens the file. Chrome
>> goes in the other direction, and does so intentionally with FileEntry.
>> I'd prefer everyone follow Chrome.
> We do so with FileEntry, in the sandbox, because it's intended to be a
> much more powerful API than File, and the security aspects of it are
> much simpler.  When the user drags a File into the browser, it's much
> less clear that they intend to give the web app persistent access to
> that File, including all future changes until the page is closed.  I
> don't think we'd rush to make that change to the spec.  And if our
> implementation isn't snapshotting currently, that's a bug.

In my reading of the spec, UAs explicitly instructed not to implement a 
snapshot. Everything in the specs talks about underlying data.
They are to keep the FileList live, and failing that, or should the 
underlying file be removed, they should throw an error when the File 
object is used with FileReader or the like.

I've written code for Chrome that detects file changes, so it'd be a bit 
of a bummer to see this feature removed without suitable replacement.

FileEntry does not currently work with D&D as well as File. I don't 
think it's caught up yet. I can't drag a FileEntry into <input 
type="file"> on another site.

>>  From drag&drop:
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html
>> "The files attribute must return a live FileList sequence...".
>>
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#live
>> "If a DOM object is said to be live, then the attributes and methods on that
>> object must operate on the actual underlying data, not a snapshot of the
>> data."
>>
>> Drag&drop continues:
>> "for a given FileList object and a given underlying file, the same File
>> object must be used each time."
>>

"Underlying" is an important distinction here.

For persistent directory access, we talked about using 
requestFileSystem(MOUNT).

-Charles

Received on Wednesday, 11 January 2012 20:36:02 UTC