[File API] File behavior under modification

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?

	Eric

[1] http://dev.w3.org/2006/webapi/FileAPI/

Received on Monday, 21 May 2012 23:06:24 UTC