On Wed, May 23, 2012 at 12:57 PM, Charles Pritchard <[email protected]> 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
