Re: [File API] File behavior under modification

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?

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