cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Want to learn some quick and useful tips to make your day easier? Check out how Calvin uses Replay to get feedback from other teams at Dropbox 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: 

Case insensitivity inconsistent in metadata for folder names

Case insensitivity inconsistent in metadata for folder names

A S.13
Explorer | Level 4

I'm working with an app that is trying to sync files from its App folder within Dropbox and the directory structure is as such:

/Apps/picpi/Ange-Art/2015-06-09-DevilsTower

Because of the App, the folder is seen as /Ange-Art/2015-06-09-DevilsTower and the directory structure on the local side is created using these names.

When I go to retrieve the file itself, the file comes across with the path /ange-art/2015-06-09-DevilsTower where the first folder is lower case and the subfolder maintains its mixed case nature.  However, because this API pull is happening on Linux, it is trying to store it into the folder /ange-art/015-06-09-DevilsTower and the previous API call gave me /Ange-Art so that is the folder that was created.

This is incredibly inconsistent and without just blowing away all mixed case scenarios and converting to all upper or all lower case, how do I get around this inconsistency?

Log file below:

https://gist.github.com/ascheel/236960176a39a8466bf6

8 Replies 8

Jack P.10
New member | Level 1

This problem has been around for a while, I suggest you don't rely on the case sensitivity.  For API V2, Dropbox drops 'path' and changes to 'path_lower'.  I hope they would put 'path' back.   Even so, your program should never expect 'path' not to be case consistency on parent and children.  

Good luck.

 

A S.13
Explorer | Level 4

bah.....  I guess I'm adding .lower() to all directory names from now on.

A S.13
Explorer | Level 4

Well, as Dropbox is case insensitive, I've reprogrammed everything to be lower case.  Since it happens in the background, it's not too big of a deal.  I do like uniformity, but this will do.  ðŸ˜‰

Greg-DB
Dropbox Staff

Dropbox and the Dropbox API are case-insensitive, as you've mentioned, so there isn't a great solution here unfortunately. This is definitely something the team is aware of, but I can't promise this is something we'll be able to improve on our side.

For reference, in v1 the last path component of the path should have the case preserved, but the other components don't have the same guarantee. In v2, we tried to make this a bit clearer by using path_lower, and only having the preserved case in the name property.

Brynn R.
New member | Level 1

Case insensitivity is stupid, and breaks things.

I am doing Eclipse based software development, and I did a 'download' to try and speed up the sync.   I discover that the downloaded zip file changed the names of some directories to all lower case.    The build system dies horribly when it can't find things where it expects them.

 

We've just upgraded to dropbox business, and it seems like more and more problems are popping up.  I am going to have to resort to copying everything to a thumbdrive all the time now - which makes me wonder what we are paying for.

Steve M.
Dropbox Staff

Brynn, I don't think your post relates to the API, so it doesn't belong here.

That said, Dropbox is case-insensitive but case-preserving. In the case you describe, I don't think case-insensitivity is a problem, but the lack of case preservation is. If the zip file was one generated by Dropbox, then this sounds like a potential product bug. I'd suggest posting in the Issues & Troubleshooting forum so someone can investigate. (Please be sure to describe how the zip file was created.)

A S.13
Explorer | Level 4

Steve, it is only case preservingin SOME situations.  When looking up the 'path' section of the metadata, only the top parent directory has the case preserved, which is absolutely pointless.

Steve M.
Dropbox Staff

"Utah J.", I was trying to help Brynn get help for what seems like a product bug that's causing him a problem.

I understand that the path field of an individual call to /metadata doesn't provide you the current casing of the full path. (You can of course walk back up the path and reconstruct the full casing if you need to, since Dropbox is case-preserving.)

Need more support?
Who's talking

Top contributors to this post

  • User avatar
    Steve M. Dropbox Staff
  • User avatar
    A S.13 Explorer | Level 4
  • User avatar
    Brynn R. New member | Level 1
  • User avatar
    Greg-DB Dropbox Staff
What do Dropbox user levels mean?