[whatwg] New File attributes creationDate, modificationDate and size
Arun Ranganathan
arun at mozilla.com
Tue May 18 16:05:02 PDT 2010
On 5/18/10 2:45 PM, Eric Uhrhane wrote:
> On Fri, May 14, 2010 at 5:05 PM, Arun Ranganathan<arun at mozilla.com> wrote:
>
>> On 5/12/10 4:25 AM, Ashley Sheridan wrote:
>>
>>> On Wed, 2010-05-12 at 00:05 -0400, Biju wrote:
>>>
>>>
>>>
>>>> It would be good if we can also get the same at server side when user
>>>> upload a file using form with file controls
>>>> ie, like the suggestion at
>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=549253
>>>> (it works even with javascript disabled)
>>>>
>>>> Also remember modificationDate can be a time before creationDate on
>>>> windows.
>>>> This is because modificationDate get copied when you copy a file,
>>>> hence it almost shows modificationDate of the actual content.
>>>>
>>>> creationDate on other hand is file creation time on the
>>>> folder/directory and when you copy a file to a new directory, it will
>>>> be showing the coping time.
>>>>
>>>> PS, for JS option there is mozilla bug 390776
>>>>
>>>>
>>>
>>>
>> I intend to update the File API so that the File object exposes creationDate
>> and modificationDate.
>>
> You might want to consider making an async getMetadata function; see
> discussion ending at [1]. Async because the modification time can
> change often, and as a generic all-metadata function because it's easy
> to expand and experiment with. And if you put that right in the File
> API, then I can inherit it from the FileSystem API instead of having
> to spec it myself ;'>.
>
>
Right now in our implementation (Fx 3.6.3), we work with files as
copies, so if the underlying file changes, the case isn't handled. But
I agree that having an asynchronous API that is exposed to web content
will allow more graceful behavior.
I'll take a look at the generic asynchronous "all-metatdata" function
and consider adding it to the File object.
-- A*
More information about the whatwg
mailing list