Re: File API: Blob and underlying file changes.

On Fri, Jan 15, 2010 at 10:36 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Fri, Jan 15, 2010 at 10:19 AM, Dmitry Titov <dimich@chromium.org>
> wrote:
> > Nobody proposed locking the file. Sorry for being unclear if that sounds
> > like it. Basically it's all about timestamps.
> > As Chris proposed earlier, a read operation can grab the timestamp of the
> > file before and after reading its content and throw exception if the
> > timestamps do not match. This is pretty good approximation of 'atomic'
> read
> > - although it can not guarantee success, it can at least provide reliable
> > detection of it.
>
> I don't understand how you intend to use the timestamp. Consider the
> following scenario:
>
> 1. User drops a 10MB File onto the a page.
> 2. Page requests to read the file using FileReader.readAsBinaryString
> and installs a 'progress' event listener.
> 3. Implementation grabs a the current timestamp and then starts reading the
> file
> 4. After 2MB of data is read the implementation updates
> FileReader.result with the partial read and fires a 'progress' event.
> 5. Page grabs the partial result and processes it.
> 6. After another 1MB of data is read, but before another 'progress'
> event has been fired, the user modifies the file such that the
> timestamp changes
> 7. The implementation detects that the timestamp has changed.
>
> Now what?
>
> You can't "throw an exception" since part of the file has already been
> delivered. You could raise an error event, but that's unlikely to be
> treated correctly by the page as this is a very rare condition and
> hard to test for, so the page author has likely not written correct
> code to deal with it.


FileReader has both 'error' and 'abort' events, in addition to 'progress'.
It seems we just can use those? There is always a possibility that async
operation that comes with partial results may fail as a whole - the only
real way to ensure its atomicity would be to reliably lock the file or/and
make a copy - which as this thread indicates are both not always possible.
So yeah, in case FileReader returned 2MB and file suddenly changed to be
only 1Mb, the next event the page should get is 'error'.

What would be other possibility?



> It's additionally not atomic since the read
> started, but was interrupted.
>
> / Jonas
>