You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
Case insensitivity inconsistent in metadata for folder names
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:
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.
bah..... I guess I'm adding .lower() to all directory names from now on.
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.
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.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.)
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.
"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.)
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
