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