W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: [File API] File behavior under modification

From: Glenn Maynard <glenn@zewt.org>
Date: Wed, 11 Jul 2012 21:02:39 -0500
Message-ID: <CABirCh9Fj7t5_S4Usp1SkjvRGZwLGDopeENwuEDdcdokXDCJxA@mail.gmail.com>
To: Arun Ranganathan <aranganathan@mozilla.com>
Cc: Eric U <ericu@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, Jonas Sicking <jonas@sicking.cc>, Kinuko Yasuda <kinuko@google.com>, Jian Li <jianli@google.com>, Alexey Proskuryakov <ap@webkit.org>, Satoru Takabayashi <satorux@google.com>, Toni Barzic <tbarzic@google.com>
On Wed, Jul 11, 2012 at 2:53 PM, Arun Ranganathan
<aranganathan@mozilla.com>wrote:

> I agree that making snapshotting clearer might be a good idea.
>
> It is true that reading size and lastModifiedDate are synchronous, but
> this seemed a small trade-off compared to data reads.
>
> My instinct is that an asynchronous API for mtime is overkill.
>

All disk I/O needs to be asynchronous.

It doesn't matter how much data you're reading.  If the file you're reading
happens to be on a DVD that needs to spin up, or a slow or timing-out NFS
mount, or even on a hard drive that happens to be powered down to save
battery, reading anything at all can take a very long time.  Disk I/O needs
to be treated like network access.

> (While I'm thining about it, does lastModifiedDate really need to be
> nullable?  Systems without file timestamps are so rare that it's probably
> better to require them to fabricate a date, so we don't introduce bugs into
> people's code for rare cases.)
>
> What's the main problem with it being nullable?  A fabricated date seems
> strange, but instead of being nullable we could spec what the fabricated
> date is.  I'm just not totally sure what the pros and cons are here.
>

If you call "d.getYear()" and d is null, you get an exception, which has a
very high chance of breaking the app if it's not checked for.  Giving an
arbitrary (but well-defined) default is much less likely to break things
that badly.  This is much more important when the null case is rare,
because nobody is going to remember to test for it.


> Can you log a bug so that I can provide guidance for this in spec?
>

Sorry, but to avoid rereading the thread, a bug for what exactly?  Do you
need anything beyond https://www.w3.org/Bugs/Public/show_bug.cgi?id=17746?


On Wed, Jul 11, 2012 at 3:02 PM, Arun Ranganathan
<aranganathan@mozilla.com>wrote:

> It would be the values at the time of the snapshot state.  (I doubt it was
> ever actually intended that lastModifiedDate always return the file's
> latest mtime.  We'll find out when one of the editors gets around to this
> thread...)
>
> I think the ideal behavior is that it reflects values at snapshot state,
> but that reads if snapshot state has modified fail.
>

To be clear--reads of the blob data fail (FileReader), but .size or
.lastModifiedDate continue to have their original values.

-- 
Glenn Maynard
Received on Thursday, 12 July 2012 02:03:07 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:53 GMT