Case-Sensitivity in API 2

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