cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Share your feedback on the Document Scanning Experience in the Dropbox App right here.

Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

files/get_metadata has incorrect case for path_display

files/get_metadata has incorrect case for path_display

Todd H.4
New member | Level 2

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?

4 Replies 4

Greg-DB
Dropbox Staff

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
New member | Level 2

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. 

 

Greg-DB
Dropbox Staff

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
Dropbox Staff

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

Need more support?
Who's talking

Top contributors to this post

  • User avatar
    Greg-DB Dropbox Staff
  • User avatar
    Todd H.4 New member | Level 2
What do Dropbox user levels mean?