Re: File API: Blob and underlying file changes.

On Fri, Jan 15, 2010 at 11:42 AM, Dmitry Titov <dimich@chromium.org> wrote:
>
>
> 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?

This doesn't address the problem that authors are unlikely to even
attempt to deal with this situation, given how rare it is. And even
less likely to deal with it successfully given how hard the situation
is reproduce while testing.

/ Jonas

Received on Friday, 15 January 2010 19:51:26 UTC