W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: File modification

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 12 Jan 2012 00:30:24 -0800
Message-ID: <CA+c2ei9pNT3zmo-=V9gCLGQM5wYAxZQS036iYRP5zdBruAtciw@mail.gmail.com>
To: Charles Pritchard <chuck@visc.us>
Cc: Eric U <ericu@google.com>, Charles Pritchard <chuck@jumis.com>, Glenn Maynard <glenn@zewt.org>, "public-webapps@w3.org" <public-webapps@w3.org>
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.

/ Jonas
Received on Thursday, 12 January 2012 12:34:21 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT