Re: File modification

On 1/12/2012 12:30 AM, Jonas Sicking wrote:
> On Wed, Jan 11, 2012 at 12:35 PM, Charles Pritchard<chuck@visc.us>  wrote:
>> 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.
> If so that's a bug in the spec.
>
> File and Blob objects are intended to contain constant data. For a
> file object returned from<input type=file>  I would expect the
> implementation to make all reads fail if the data changes on disk. I
> know we don't do this in Firefox right now, but I consider that a bug.

The FileList object is what we're looking at.  Yes, File and Blob should 
be constant data.

When the underlying File data changes, the FileList object should point 
to the new file or otherwise not return the item in the list.

Yes, Firefox has a bug: it is not creating a new File object when 
FileList is accessed for a modified file.
It's not throwing an error on when the old File object is used.

This seems like a relatively easy fix to FileList and the File object.


-Charles

Received on Thursday, 12 January 2012 18:05:26 UTC