Child Item

files/get_metadata has incorrect case for path_display

If I fetch the metadata for a folder and check the path_display, I get the mixed case path as desired.

But if I fetch the metadata for a file within that folder, the entire path is lower case. path_display and path_lower are identical. path_display does NOT match what is displayed on the Dropbox website.

I noticed the behavior in Java but confirmed it in API explorer. You can see the behavior via https://dropbox.github.io/dropbox-api-v2-explorer/#files_get_metadata.

This seems like a flat-out bug. Can anyone else confirm? What is the process for bug reporting at Dropbox?

Find more posts tagged with

API

Abuse

Comments

Greg-DB

Hi Todd, this is a good place to report bugs like this.

Are you seeing this only for deleted metadata, or for all metadata? There's a known issue for this for deleted metadata, but if you're also seeing this for non-deleted metadata, please share a sample so we can look into it. Thanks in advance!

Todd H.4

Having tried to reproduce this with non-proprietary files I see the problem is more subtle. It has to do with folders being removed and added back with a different case.

Steps to reproduce:

Create a folder called Test
Add a folder called lowercase.
Delete the folder named lowercase
Add a folder named LowerCase
Add a file named Error.png

We have:

Now we let's look at the API view. It correctly shows the path_display of “/Test/LowerCase”

But when I get the metadata for the file, it shows the incorrect case for the folder which was deleted and added with a different case. It shows “/Test/lowercase/Error.png” but I would expect “/Test/LowerCase/Error.png”

Knowing what I know now, I can code around the problem. But still ... very curious.

Greg-DB

Thanks for following up with that Todd. That behavior is expected. Dropbox itself is case-insensitive, with attempts to be case-preserving. However, due to various specifics, the API can't always return the expected case for every path component. So, for any file or folder metadata, the filename/last path component should have the preserved case, but other path components are not guaranteed to.

We realize this is non-ideal of course and are looking into ways to improve it, but I don't have a solution to offer right now.

If you need the preserved casing, you'll need to build it up from the last component in each parent entry.

Greg-DB

For reference, the known issue with lowered path_display values for deleted files in particular should be fixed now.