Re: File API: Blob and underlying file changes.

Another reply, in WebKit Bugzilla (
https://bugs.webkit.org/show_bug.cgi?id=32912#c10):

 *Comment #10 <show_bug.cgi?id=32912#c10> From Darin Fisher (:fishd,
Google)<fishd@chromium.org>
 2010-01-11 23:08:49 PST* (-) <#> [reply <#add_comment>]

<input type=file> does not require the referenced file to remain unmodified
until it is submitted, and since Blob can just be a pointer to the file
referenced by an INPUT element, I think it should similarly not care if the
file is modified.  We should probably just treat Blob as a path to data.  This
implies not caching file length.


Agree, that sounds reasonable (at least backward-compatible).

What about 'derived' Blobs that are obtained using Blob.slice(start, length)
API? Since the size and content of the original file can change, if the
implementation does not actually copy data at the moment of slice creation,
then those slices will start pointing to random ranges in the underlying
file.

We could:
- copy data during slice() (too slow and probably incorrect)
- do copy-on-file modification
- mark Blob invalid (throw error on all operations? there is no property to
indicate)
- make Blob refer to range (0,0)
- do nothing, truncate the range to new file size.

What's the right thing to do? It feels that for correctness, some way to
invalidate the slice is better since it will prevent scenarios when
XHR.send(blob) and form.submit() will actually send different data...

Dmitry


On Fri, Jan 8, 2010 at 11:03 PM, Dmitry Titov <dimich@chromium.org> wrote:

> Adding reply from Jonas Sicking from anther list (which I used first by
> mistake :( )
>
> Technically, you should send this email to the webapps mailing list,
>  since that is where this spec is being developed.
>
> That said, this is a really hard problem, and one that is hard to
> test. One thing that we decided when we did security review on this
> stuff at mozilla is that if a File object is ever passed cross origin
> using postMessage, then the File object that the other origin has
> should not work if the file is changed on disc. For some definition of
> "not work".
>
>
> On Fri, Jan 8, 2010 at 2:21 PM, Dmitry Titov <dimich@chromium.org> wrote:
>
>> Hi,
>>
>> Does the Blob, which is obtained as File (so it refers to an actual file
>> on disk) track the changes in the underlying file and 'mutates', or does it
>> represent the 'snapshot' of the file, or does it become 'invalid'?
>>
>> Today, if a user selects a file using <input type=file>, and then the file
>> on the disk changes before the 'submit' is clicked, the form will submit the
>> latest version of the file.
>> This may be a surprisingly popular use case, when user submits a file via
>> form and wants to do 'last moment' changes in the file, after partial
>> pre-populating the form. It works 'intuitively' today.
>>
>> Now, if the page decides to use XHR to upload the file, I think
>>
>> var file = myInputElement.files[0];
>> var xhr = ...
>> xhr.send(file);
>>
>> should also send the version of the file that exists at the moment of
>> xhr.send(file), not when user picked the file (for consistency with form
>> action).
>>
>> Assuming this is desired behavior, what should the following do:
>>
>> var file = myInputElement.files[0];
>> var blob = file.slice(0, file.size);
>> // ... now file on the disk changes ...
>> xhr.send(blob);
>>
>> Will it:
>> - send the new version of the whole file (and update blob.size?)
>> - send captured number of bytes from the new version of the file (perhaps
>> truncated since file may be shorter now)
>> - send original bytes from the previous version of the file that existed
>> when Blob was created (sort of 'copy on write')
>> - throw exception
>> ?
>>
>>
>> Thanks,
>> Dmitry
>>
>
>