W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: [File API] File behavior under modification

From: Charles Pritchard <chuck@jumis.com>
Date: Wed, 23 May 2012 16:00:14 -0700
Message-ID: <4FBD6BFE.7050409@jumis.com>
To: Glenn Maynard <glenn@zewt.org>
CC: Kinuko Yasuda <kinuko@chromium.org>, Eric U <ericu@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, Arun Ranganathan <aranganathan@mozilla.com>, Jonas Sicking <jonas@sicking.cc>, Jian Li <jianli@google.com>, Alexey Proskuryakov <ap@webkit.org>, Satoru Takabayashi <satorux@google.com>, Toni Barzic <tbarzic@google.com>
On 5/23/2012 3:32 PM, Glenn Maynard wrote:
> On Wed, May 23, 2012 at 12:57 PM, Charles Pritchard <chuck@jumis.com 
> <mailto:chuck@jumis.com>> wrote:
>     I think that's where the spec writing for this is challenging. I'd
>     lean toward documenting what's really out there instead of
>     mandating snapshot capabilities in the file system.
> It doesn't mandate snapshot capabilities.  If the file is changed, 
> reading the File doesn't give you the old data; it fails with an 
> error.  That's easy to for the browser to check: compare the mtime of 
> the file (probably both before and after the read, to avoid races).  
> Native applications could fool this if they want to, but this isn't a 
> problem in practice.  Also, implementations are free to use other 
> mechanisms to implement the "snapshot state" concept (eg. file change 
> notification APIs).

OK, I agree with this method. It'll fix both the Mozilla and WebKit 
families in respect to their current behavior. It may already be 
Mozilla's behavior (I'm a bit behind on tracking it).

Received on Wednesday, 23 May 2012 23:00:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:34 UTC