Thanks for the post! Can you clarify what you mean when you say "the metadata of file or folder by such path then Dropbox returns nothing"? The Dropbox API is case-insensitive, so you should be able to query by path regardless of the case. If that's not working for you, please share the code you're using and the unexpected output.
For reference, Dropbox is case-insensitive, and attempts to be case-preserving, but sometimes you won't see the original expected case. You should use path_lower when performing operations, as that's the canonicalized version of the path. You should use path_display for display purposes, where the case will be preserved to the extent possible. Even in path_display though, the original casing isn't always available. There's a note about this in the API v2 documentation, under "Case insensitivity":
"Also, while Dropbox is case-insensitive, it makes efforts to be case-preserving. Metadata.name will contain the correct case. Metadata.path_display usually will contain the correct case, but sometimes only in the last path component. If your app needs the correct case for all components, it can get it from the Metadata.name or last path component of each relevant Metadata.path_display entry."
There's also some information in the documentation for "path_display" if you expand "FileMetadata", e.g., under /2/files/get_metadata. FileMetadata.name will contain the case-preserved name, so the workaround would be to build the path up from that.
We understand this is non-ideal of course, and I'll forward this on to the team as feedback, but I can't make any promises as to if or when this might be improved in the future.
