You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some filesystems (e.g. those exposed using the Android DocumentsProvider API) allow files that have an unknown size. One use case here is when a file is generated when accessed. For example, an online drawing app has an internal representation of the user's images. It can expose a virtual filesystem of .png files for each drawing. However these png's will actually be generated at the time the file is accessed and so the size isn't known ahead of time (e.g. when listing the files).
The current file APIs require a size ahead of time and don't provide a constant to specify an unknown size. This would be something nice to add.
I think this is a dupe of #101 -- but highlighting the core requirement of the proposed getMetadata API that it needs to allow the implementation to return null fields (in this case, return a null file size) so that we can return as much metadata as possible without fetching the entire file, which in the DocumentsProvider case, is the only way to get the file size.
Some filesystems (e.g. those exposed using the Android DocumentsProvider API) allow files that have an unknown size. One use case here is when a file is generated when accessed. For example, an online drawing app has an internal representation of the user's images. It can expose a virtual filesystem of .png files for each drawing. However these png's will actually be generated at the time the file is accessed and so the size isn't known ahead of time (e.g. when listing the files).
The current file APIs require a size ahead of time and don't provide a constant to specify an unknown size. This would be something nice to add.
@mkruisselbrink
The text was updated successfully, but these errors were encountered: