cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Update: Find information on Dropbox support during COVID-19 here
Close
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted

files/get_metadata has incorrect case for path_display

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

Re: files/get_metadata has incorrect case for path_display

Dropboxer
Dropboxer

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! 

Highlighted

Re: files/get_metadata has incorrect case for path_display

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

 

Highlighted

Re: files/get_metadata has incorrect case for path_display

Dropboxer
Dropboxer

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.

Highlighted

Re: files/get_metadata has incorrect case for path_display

Dropboxer
Dropboxer

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

Work Smarter with Dropbox

The way we work is changing. Share and discover new ways to work smarter with Dropbox in our community.

Sound good? Let's get started.
Who's talking

Top contributors to this post

What do Dropbox user levels mean?
Need more support?