Re: File modification

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" <jonas@sicking.cc> wrote:

> On Wed, Jan 11, 2012 at 12:35 PM, Charles Pritchard <chuck@visc.us> wrote:
> > On 1/11/2012 12:27 PM, Eric U wrote:
> >>
> >> On Wed, Jan 11, 2012 at 12:22 PM, Charles Pritchard<chuck@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
>