files/get_metadata has incorrect case for path_display

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! 

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:

1. Create a folder called Test
2. Add a folder called lowercase.
3. Delete the folder named lowercase
4. Add a folder named LowerCase
5. 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. 

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.

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