Child Item

Detect if a file is an image

I am integrating the dropbox API in my application extension which is a filemanager. I need to check if the file saved on the dropbox server is an image or not.

Reason why i need is that i cache the whole directory tree on my local system and then user can navigate through the tree easily without sending API calls at every folder navigate request.

So i scan the whole tree on application start and write those file to the disk and while i do that i have to generate the thumbnails for the image files and i use the get_thumbnails_batch function to generate all the thumbnails once in the batch of 25 files at a time. But to do that i first need to sort out those files which are valid images but i can find any thing related, the get_metadata function also dont return any property through which i can check it.

Find more posts tagged with

API

Abuse

Accepted answers

Greg-DB

Right, to be clear, the include_media_info parameter is only deprecated on /2/files/list_folder, not /2/files/get_metadata. And yes, for a substantial number of files, calling /2/files/get_metadata for each one would not be very efficient.

And that's correct, for the second option I am referring to parsing the file extension from the `name`. And yes, the issue you refer to are the false positives I mentioned.

No, Dropbox does not validate that a file's extension and content match. The client sets the filename and extension when sending the data, and Dropbox will not reject it if it looks it doesn't match.

All comments

Greg-DB

There are two ways you may want to approach this, each with their own advantages and disadvantages:

For each file, call /2/files/get_metadata with include_media_info:true and check the resulting file.media_info.metadata is a PhotoMetadata. The advantage here is that this would indicate that the file is a valid image, since it makes Dropbox actually inspect the file. Some disadvantages are that you may get some false negatives, if Dropbox can't parse the image, and that it would be less performant since you need to call for every file.
Call /2/files/list_folder[/continue] (with recursive:true, if desired) for the folder to get the whole file listing, and check for files with `name`s that end in any of the image file extensions supported by /2/files/get_thumbnail_batch. One disadvantage is that you may get some false negatives, since you can't guarantee that every image will have a proper image file extension. Some advantages though are that it would be more performant, and would directly align with what /2/files/get_thumbnail_batch supports anyway.

By the way, I linked to the HTTPS endpoint themselves above, but if you're using an official SDK, there will be corresponding native methods for each of those.

buttflattery

Oops! i mixed the include_media_info option of the list_folder with the meta_data assuming the include_media_info option is going to be deprecated. But this option wont be much efficient and will make the process delayed in case of files are more than 100 or so along with consuming too much API calls.

About the second option i didnt quiet get what you are saying. Do you mean that i should extract the extension from the the name and match it with the supported file types? Wont that be unreliable just to rely on the name as it could be changed to anything like i change a .jpg image to a .pdf file then what?

Does dropbox validates a file based on its extension and content both when we save there and rejects it?

Greg-DB

And that's correct, for the second option I am referring to parsing the file extension from the `name`. And yes, the issue you refer to are the false positives I mentioned.

No, Dropbox does not validate that a file's extension and content match. The client sets the filename and extension when sending the data, and Dropbox will not reject it if it looks it doesn't match.

buttflattery

Although it is not a solution but a limitation i must say on dropbox end and this is not an optimal approach but anyhow there isnt any other thing i can do. so marking it as an answer.