Re: File modification

On 1/12/12 12:53 PM, Arun Ranganathan wrote:
> On Jan 12, 2012, at 6:58 AM, Kyle Huey <me@kylehuey.com 
> <mailto:me@kylehuey.com>> wrote:
>
>
>         On Thu, Jan 12, 2012 at 3:45 PM, Glenn Maynard <glenn@zewt.org
>         <mailto:glenn@zewt.org>> wrote:
>
>             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.
>
>
>         Gecko nightlies are capable of storing File objects in
>         IndexedDB,  We are doing "deep" copies (what is retrieved from
>         the database is always a copy of the file as it was when it
>         was placed in the database).
>
>
>     Oh I'm glad to see this one! Is it Blob and File that can be put
>     into IDB? How do I create a new File (with a name field) from a Blob?
>
>
> Charles: see the thread on making Blobs constructable -- follow 
> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0439.html

http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0918.html

Seems like the consensus was to stay away from Blob to File methods. 
FileEntry and [a download] being the heirs apparent.

> The File API specification should do a better job describing what 
> happens to a File if the underlying resource changes.  We use the word 
> immutable, but I think we have to make this substantially clearer.

My take on a File object that's been modified is that the file no longer 
exists.
"User agents MUST process reads on files that no longer exist at the 
time of read as errors"
"A file may change on disk since the original file selection, thus 
resulting in an invalid read."

FileList is live; and UAs can go several ways with it. They can return 
new File objects, with updated information (yes, please); or they can 
otherwise cut out modified files or later, throw the security error as 
specified:  "Post-selection file modifications occur when a file changes 
on disk after it has been selected. In such cases, user agents MAY throw 
a SecurityError for synchronous read methods, or return a SecurityError 
DOMError for asynchronous reads.".

It's a consideration, anyway. I don't think people expect that, if they 
select a file for uploading, then modify the file before hitting submit, 
that they'll no longer upload a file. It would, I suppose, "disappear" 
from the Chosen file option.

There is a significant difference between selecting files and mounting a 
directory for persistent access. In one of them, the files are listed 
and new files are not added. So I may select a single file, and it'll 
show up in input type=file, or I'll see a count of the files I selected. 
With mounting a directory, I'm given continued access to poll for new 
files. I think that's enough of a distinction to keep the current 
behavior of allowing persistent access to selected files via FileList.

If it's not enough of a distinction, I'd like more semantics added to 
requestFileSystem to re-establish the persistent selection of files.

-Charles