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-Sensitivity in API 2

Case-Sensitivity in API 2

Keith B.7
Helpful | Level 7
Go to solution

Hi,

 

Short version of this question:

 

Is DBFILESMetadata's .pathDisplay property guaranteed to always use the correct case in its last path component, as .DBMetadata's .path property was in API 1?

 

(Everything below is just a longer-winded way of asking that. 🙂 )

 

I've always had an issue with the conflict between Dropbox being case-insensitive and Apple's iOS file system being case-sensitive. In API 1, both DBMetadata's -filename was guaranteed to be case-sensitive, and -path was guaranteed to be case-sensitive for the last path component, while other path components may or may not use the correct case.

 

I use this behaviour to build up full case-correct paths by iterating through all paths and replacing components in a path with the case-sensitive counterparts from smaller paths. For instance, if I have the following paths:

 

/Folder

/folder/Another Folder

/folder/another folder/File.txt

 

I can iterate through and fix things up so that they end up as:

 

/Folder

/Folder/Another Folder

/Folder/Another Folder/File.txt

 

I need to do the same with API 2, but the documentation is a little unclear on what behaviour is guaranteed. This is what the HTTP endpoint documentation says:

 

"Also, while Dropbox is case-insensitive, it makes efforts to be case-preserving. Metadata.name will contain the correct case. Metadata.path_display usually will contain the correct case, but sometimes only in the last path component. If your app needs the correct case for all components, it can get it from the Metadata.name or last path component of each relevant Metadata.path_display entry."

 

From this, I know that DBFILESMetadata's .name property is guaranteed to use the correct case. What I'm less clear on is whether the .pathDisplay property is also guaranteed *always* to use the correct case for the *last* path component. The quote above just says that the display path will usually contain the correct case but sometimes only for the last path component - that doesn't seem to make any guarantees that the last path component always uses the correct case. However, it then goes on to say that you can use the last path component of the path_display entry to get the correct case. So is path_display guaranteed, then, just as it was in API 1, to always use the correct case for the last path component?

 

Thanks!

Keith

1 Accepted Solution

Accepted Solutions

Greg-DB
Dropbox Staff
Go to solution
Yes, API v2's "pathDisplay" is the same as API v1's "path", so the last path component (only) is guaranteed to have the expected casing.

View solution in original post

2 Replies 2

Greg-DB
Dropbox Staff
Go to solution
Yes, API v2's "pathDisplay" is the same as API v1's "path", so the last path component (only) is guaranteed to have the expected casing.

Keith B.7
Helpful | Level 7
Go to solution

Great, thank you!

Need more support?
Who's talking

Top contributors to this post

  • User avatar
    Keith B.7 Helpful | Level 7
  • User avatar
    Greg-DB Dropbox Staff
What do Dropbox user levels mean?