FYI, I don't think this is clear for File from the spec. It's even more important if File objects are stored in History or IndexedDB; that it should be a *shallow* copy, with enough information stored to invalidate it if the underlying file changes, doesn't seem to be specified. (As far as I know, nobody implements that yet; being able to eg. retain open files in History states would be extremely useful.)
Allowance should be made for the fact that this is just best-effort; if another application modifies blocks of the file in-place without changing the mtime or size of the file, there's usually no reasonable way for a browser to detect it. On Jan 12, 2012 12:30 AM, "Jonas Sicking" <jo...@sicking.cc> wrote: > On Wed, Jan 11, 2012 at 12:35 PM, Charles Pritchard <ch...@visc.us> wrote: > > On 1/11/2012 12:27 PM, Eric U wrote: > >> > >> On Wed, Jan 11, 2012 at 12:22 PM, Charles Pritchard<ch...@jumis.com> > >> wrote: > >>> > >>> On 1/11/2012 9:00 AM, Glenn Maynard wrote: > >>>> > >>>> > >>>> This isn't properly specced anywhere and may be impossible to > implement > >>>> perfectly, but previous discussions indicated that Chrome, at least, > >>>> wanted > >>>> File objects loaded from input elements to only represent access for > the > >>>> file as it is when the user opened it. That is, the File is immutable > >>>> (like > >>>> a Blob), and if the underlying OS file changes (thus making the > original > >>>> data no longer available), attempting to read the File would fail. > >>>> (This > >>>> was in the context of storing File in structured clone persistent > >>>> storage, > >>>> like IndexedDB.) > >>>> > >>> Mozilla seems to only take a snapshot when the user opens the file. > >>> Chrome > >>> goes in the other direction, and does so intentionally with FileEntry. > >>> I'd prefer everyone follow Chrome. > >> > >> We do so with FileEntry, in the sandbox, because it's intended to be a > >> much more powerful API than File, and the security aspects of it are > >> much simpler. When the user drags a File into the browser, it's much > >> less clear that they intend to give the web app persistent access to > >> that File, including all future changes until the page is closed. I > >> don't think we'd rush to make that change to the spec. And if our > >> implementation isn't snapshotting currently, that's a bug. > > > > > > In my reading of the spec, UAs explicitly instructed not to implement a > > snapshot. > > If so that's a bug in the spec. > > File and Blob objects are intended to contain constant data. For a > file object returned from <input type=file> I would expect the > implementation to make all reads fail if the data changes on disk. I > know we don't do this in Firefox right now, but I consider that a bug. > > / Jonas >