Re: [File API] File behavior under modification

On Thu, May 24, 2012 at 8:27 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, May 21, 2012 at 4:05 PM, Eric U <ericu@google.com> wrote:
>
>> According to the latest editor's draft [1], a File object must always
>> return an accurate lastModifiedDate if at all possible.
>> "On getting, if user agents can make this information available, this
>> MUST return a new Date[HTML] object initialized to the last modified
>> date of the file; otherwise, this MUST return null."
>>
>> However, if the underlying file has been modified since the creation
>> of the File, reads processed on the File must throw exceptions or fire
>> error events.
>> "...if the file has been modified on disk since the File object
>> reference is created, user agents MUST throw a NotReadableError..."
>>
>> These seem somewhat contradictory...you can always look at the
>> modification time and see that it's changed, but if you try to read it
>> after a change, it blows up.
>> The non-normative text about security concerns makes me think that
>> perhaps both types of operations should fail if the file has changed
>> ["... guarding against modifications of files on disk after a
>> selection has taken place"].  That may not be necessary, but if it's
>> not, I think we should call it out in non-normative text that explains
>> why you can read the mod time and not the data.
>>
>> This came up in https://bugs.webkit.org/show_bug.cgi?id=86811; I
>> believe WebKit is currently noncompliant with this part of the spec,
>> and we were debating the correct behavior.  Currently WebKit delays
>> grabbing the modification time of the file until it's been referenced
>> by a read or slice(), so it won't notice modifications that happen
>> between selection and read.  That was done because the slice creates a
>> "File object reference", but in my reading creating the File referring
>> to the file should be the time of the snapshot, not creating a Blob
>> referring to a File.
>>
>> What's the correct behavior?
>>
>
> In Gecko we currently lazily in some cases get the file size and the
> lastModificationDate (which we just implemented the other day). However
> getting that lazily means that we sometimes have to do synchronous IO which
> is something we want to avoid. Hence we're working towards always getting
> the file size and last modification date when the File object is
> instantiated and would never change after that.
>
> I would imagine other UAs would want to avoid such synchronous IO too?
>

Changing the behavior of .lastModificationDate and .size might affect
existing Web applications, but I like this approach.
It makes things clearer, UAs can avoid synchronous IO (yes, we want to
avoid it) and File becomes a purely constant snapshot. It sounds saner to
me (especially now that we have an alternative live file interface, i.e.
FileEntry).

We absolutely should not have an API which forces implementations to do
> synchronous IO, hence I don't think we can require that
> lastModificationDate should stay up-to-date, or that reading from it should
> throw if the file has changed on disk. The only operations that we can make
> fail are asynchronous ones, which means that we can only make file-reading
> fail.
>

The wording in the spec is unfortunate since it says that reading should
> "throw". Instead we should say that reading should fail, and then leave it
> up to the various APIs to define what happens when reading fails.
>
> / Jonas
>
>