Re: File modification

On 1/13/12 11:13 AM, Arun Ranganathan wrote:
> On 1/12/12 12:53 PM, Arun Ranganathan wrote:
>
>         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.
>
>
> Well, the consensus was to introduce a constructor to Blob, which I'm 
> about to do :)

Sorry, I misread that thread; and misremembered it. I saw it as 
appending multiple strings.
I'm happy to see the Blob constructor happening!


>         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."
>
>
> Just to be clear, "disappearing" a file from FileList might is the 
> same as|
>
> item(index)
>
> |returning null for the the index'th item.  Maybe this should be 
> enforced as well for any kind of modification?  This isn't what Fx 
> does today.

I'm fine with that being the defined behavior for FileList when 
implementations have elected to remove modified files.
It's still optional: implementations MAY remove modified files from the 
FileList, those that do MUST return null for the index'th item.

I'm hoping they don't go down that route. It may mean a disconnect 
between the results of submitting a post
and the files available to the scripting environment.

Again, I don't imagine that <input type="file"> and a subsequent 
.submit() would result in an empty POST when the user modifies the 
underlying file.
Though it should do so if the user deletes or renames the underlying 
file. I suppose things could get nasty, though, if the user modifies the 
file while the post is happening. I don't want to think about those kind 
of race conditions. Hopefully the UA can put a temporary write lock on 
those files.

Well... I'm satisfied on this topic. I think we've incrementally 
improved what the File API will specify.

-Charles