Getting file metadata

[jespertheend]

Would it be possible to include some sort of way to get the metadata of a file? Currently in Chrome when calling FileSystemFileHandle.getFile() returns a File objects with its lastModified value set to the current date and time. It would be nice to at least have this value set to the modified value of the actual file. But having access to other metadata values could be desirable.

[oyiptong]

What metadata would be useful for you?

And also, what use-cases do you have in mind?

[oyiptong]

If you find bugs with the implementation, please file at https://crbug.com with the Blink>Storage>FileSystem component.

Thank you for filing issues, it helps a lot!

[jespertheend]

I wanted to monitor for file changes (#72) so looking at the modified value would be useful. But other timestamps such as created, opened and downloaded could be useful as well.

[mkruisselbrink]

lastModified always being the current time I would indeed consider a bug in our implementation. We should definitely fix that, so indeed please file a chromium bug for that.

For other metadata I would like to understand better what it would be useful for. Do you have any particular use cases in mind you would want to use that data for?

[jespertheend]

Alright I've submitted it (1018945).
My specific use case would be to see if a file has changed on the users disk. But now that I think about it, having the lastModified value would be enough for this to work.

I can't really think of a good use case for meta data. I initially thought it would be nice for a web based file browser, or a music library for instance. But I think I misunderstood how metadata works a bit. I think most of the metadata of music is stored in the file itself so this should already be accessible.

So I'm not sure how high of a priority this should be.

[jimmywarting]

I have been thinking about it also. Long time ago i made a tool that would calculate/visualize what takes up most space in a directory with a pie/sun chart. that meant i had to loop over each file/directory and get all file sizes.

Now i don't know what a File dose under the hood if it's just a references to the actual file on the disk.
but i would not want to create a clone/snapshot of the file just to get the file's size

[mkruisselbrink]

At least in chrome creating a File doesn't do anything other than stat-ing the file to get its size and last modified date.

I'll leave this open to track investigating eventually exposing more metadata, although probably not high priority.

[EricSimons]

Are there any plans to expose the lastModified property on directory listings as well? This is important esp in regards to #72

[jespertheend]

Getting the last modified date from the files requires you to fileHandle.getFile(). I'm not too sure on the specifics, but if getFile() loads the file into memory that would be a very inefficient of getting the last modified date.

[jimmywarting]

Getting the last modified date from the files requires you to fileHandle.getFile(). I'm not too sure on the specifics, but if getFile() loads the file into memory that would be a very inefficient of getting the last modified date.

i second this. It's unclear what a File/Blob is under the hood. Sometimes it's a file references to some place on the disk, sometimes it's snapshot. Large files created with new File(chunks, name) gets pegged to the disk, while small files is stored in the memory. And all browser dose it different under the hood. what response.blob() those is also a mystery to me. is it held in memory or temporary saved on the disk? if that is turned into a blob url and saved with a[download] is the file then "moved" or copied over to the place where x wants to save it?

Somewhere i heard that in http2 a blob can potentially just be a references to a remote data stream without having to download the actual content until you actually need it.

sry, was a bit of topic there.

[mkruisselbrink]

I agree we want a separate getMetaData or similer method. While in most cases calling getFile should be pretty efficient, having a separate method would be way clearer as being efficient. Also for directories we would need this anyway.

[jimmywarting]

...I suppose a getMetaData would be easier to garbage collect
...A Blob has to be saved into the aka "BlobStore" so it can be sharable with other workers/threads and work with object urls

A metadata could just be handed over to the developer without something being stored in the BlobStore
So it would not have any other references

I can imagine how long the list at chrome://blob-internals would be if i just scanned a folder to gather size information to create something like a daisydisk app

[a-sully]

This issue has been ported to the new spec: whatwg/fs#12