Re: Filesystem events

On Wed, May 29, 2013 at 3:34 PM, SULLIVAN, BRYAN L <bs3131@att.com> wrote:
> -----Original Message-----
> From: Jonas Sicking [mailto:jonas@sicking.cc]
> Sent: Wednesday, May 29, 2013 3:25 PM
> To: SULLIVAN, BRYAN L
> Cc: Charles Pritchard; piranna@gmail.com; public-webapps@w3.org
> Subject: Re: Filesystem events
>
> On Wed, May 29, 2013 at 3:17 PM, SULLIVAN, BRYAN L <bs3131@att.com> wrote:
>> From: Charles Pritchard [mailto:chuck@jumis.com]
>> Sent: Wednesday, May 29, 2013 3:08 PM
>> To: piranna@gmail.com
>> Cc: public-webapps@w3.org
>> Subject: Re: Filesystem events
>>
>>
>>
>> We didn't come to much of a resolution.
>> It was suggested that the current behavior in browsers was incorrect; that
>> the File should become inaccessible if/when it changes.
>>
>> <bryan> I disagree, the fact that re-accessing a file object loads the
>> latest version of the file is a valuable feature IMO, even if it was not
>> intentional. I don't know if preventing that is what you meant, but further
>> to require that the user reselect a file if it has changed would be a UX
>> killer.
>
> File objects should be immutable. That was one of the core design
> principles that they were built around.
>
> If we want <input type=file> to provide "live" access to on-disk
> files, then new File objects should be returned from
> HTMLInputElement.files whenever the on-disk files change. That would
> need to be defined by the HTML spec though.
>
> <bryan> OK, but that sounds like one of those "good UA design" principles that ignores the actual effect upon apps and users. I would prefer to keep this "bug" around until the new/better design is implemented.

I would expect that this doesn't work in most current UAs. Most UAs
likely cache the size of the File inside the File object, and so even
if the file changes on disk you can't see the new size, and possibly
can't read past the cached size.

/ Jonas

Received on Wednesday, 29 May 2013 22:45:10 UTC