Re: [File API] File behavior under modification

On Wed, May 23, 2012 at 12:57 PM, Charles Pritchard <chuck@jumis.com> wrote:

> I can't imagine that Mozilla's behavior here is intended. Only by
> returning a live mtime can authors be aware of whether or not the file has
> changed from a previous state.
>

No, you can find out simply by requesting a read (even a 0-byte one should
work, I think) and seeing if it fails.  Also, there's no guarantee that the
mtime is what the browser uses to determine whether a file has changed,
where simply attempting a read doesn't have that problem.

> We did go through this discussion quite awhile ago when I recommended
file watcher hooks (which are available on engines like node.js).

(This would be far more complicated.  None of this precludes it, but it's
not needed for any of this.)

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).

-- 
Glenn Maynard

Received on Wednesday, 23 May 2012 22:33:28 UTC