Wrong character case of folder name when calling listFolder using Sync API

Dropbox and the API itself are case insensitive, so in some cases you will see this behavior. (We realize this is non-ideal of course and are looking into ways to improve.) That said, the best solution here is to do a case-insensitive search in your code too.

Also, the last path component will always be the expected case though, so alternatively you can build up the paths manually on your side just using those.

Ok, at least I can feel confident it wasn't something I did wrong. I'll compensate by doing a case insensitive search.

Ok, so this is actually now causing me some troubles on iOS. It wasn't a problem on OS X because OS X's file system is case insensitive. But it seems that iOS 8's file system is case sensitive.

So I'm copying a file from Dropbox into another folder when Dropbox notifies me that there's a new file. I create the incoming folder hierarchy and store the file.

But this is what I'm getting from listFolder now:

/attachments/5a21eee5-32b1-48e4-9a44-578234fb3285/lib_blank3:69FE45C7-3CCF-4F22-AD8E-842A034D69B5/Viveza%202%20invoice.pdf

The problem is attachments and 5a21eee5-32b1-48e4-9a44-578234fb3285 are in lowercase. There are identical folders in the file system with the same names, but with different case. For example, there's Attachments AND attachments now.

What should have happened is the 5a21eee5-32b1-48e4-9a44-578234fb3285 folder should have been put INTO the Attachments folder. And if there was already a 5A21EEE5-32b1-48E4-9A44-578234FB3285, any subfolders or files should be put inside that folder. But that can't happen now.

In OS X these folders and files are in the correct case hierarchy because the folders were created on OS X. In my current test in iOS, the folders were not created on iOS, but are being synced from the folders created on the Mac.

In fact, I have a couple of duplicated folders now that differ only by case: Attachments, attachments and Imports, imports.

Couldn't Dropbox just maintain the existing case of the files properly when returning their paths in the listFolder method?

I really don't understand what logic Dropbox Sync uses for converting folder names to lowercase. Because in this example with direct output from the listFolder command, the first 2 folders are in lowercase, but the second 2 folders in the hierarchy are not. The folder hierarchy as uploaded to Dropbox should be:

/Share/Attachments/1EA9CC59-D0A8-4F82-8054-12DA1DC129C8/478660E3-A90E-4190-9B63-E99B46161B0C

but instead I get this:

DBFileInfo(path='/share/attachments/1EA9CC59-D0A8-4F82-8054-12DA1DC129C8/478660E3-A90E-4190-9B63-E99B46161B0C', isFolder=YES, modified=2015-02-02 10:43:24 +0000, size=0, thumbExists=NO, icon=folder)

It makes a real big difference with iOS syncing because of the case sensitive nature of the file system. If I don't have the folder already in the file system, I have no choice but to create it as provided by the API because I don't know what the case should be all the time. The folder names can be provided by the users. So imagine if you're syncing from Mac to iOS. The user creates a folder hierarchy on the Mac side. On the iOS side when I receive the folder hierarchy, I get a mix of cases that don't match the Mac side. I end up creating the hierarchy on the iOS side with whatever case I get from the API. Next, the iOS side goes to write to the same folder hierarchy, but now the case in the file system is different from what the code is expecting the case to be. Now we have a problem on iOS because it will create a duplicate hierarchy, but with different case.

Is there any possibility that Dropbox can fix this on your end? What was the logic behind the decision to change the case of a folder hierarchy that a user has provided to you when returned from the listFolder call?

Thanks for the additional feedback Brendan. I'm sending this along to the team as a request to improve this.

Thanks Greg, I appreciate that.

Do you have any suggestions on how I can work around this problem for now?

The only thing I can think of right now is before I write the file out that's downloaded from Dropbox to a path in the local file system is to first load up a list of all the files and folders from the local file system and then do a case insensitive search on the list. Then if I find a match, use the case of the path from the file system instead of the case of the path that I receive from Dropbox. But this has to be done for every level of the hierarchy, which of course is going to have a performance impact, not to mention more potential for bugs and/or unforeseen circumstances.

What was the technical reason for changing the case in the response? Is it a bug on your side? Perhaps if there was some very good reason, it may help me to learn something I didn't know before.

The main recommendation is just to operate in a case insensitive manner to match the Dropbox API. Also, whenever possible, just use the SDK for your file operations, as opposed to trying to sync with the local filesystem manually. The SDK caches files you open for you automatically anyway.

Regarding the technical details, there isn't really much to share that would be helpful from an API client's perspective. Dropbox is a large system with many components, so there isn't a simple answer here.

I am syncing with a local file system because I needed quick access to local files and I also needed NSURLs to local files. I tried using just the Dropbox API, but then when I realized that I needed to be able to make a backup of my files and store them all in a zip file, I was required to load all the files one by one into memory, write them to a temporary location in the file system, then add them to the zip file. It seemed like it would become a huge performance issue. I'm often dealing with thousands of files in my app, so performance is critical.

Syncing with a local file system allows my app to do that in the background while the user can still interact with it. Then when it comes time to make a backup, the files would come from the local file system instead of having to potentially download from Dropbox and then deal with loading files into memory, then writing out files to some temporary location in order to add them to the zip file.

And also some of my files are SQLite database files and I can't tell FMDB to use a DBFile. I have to give it a path to a regular file on disk.

It just makes it much more complicated to work with files given the case can change even while referencing the same folders.

I have also run into this exact same issue which has caused me to develop a very inefficient work around in IOS which is prone to bugs.

Gregory, you mentioned that you would request an improvement to this issue back in February and I was wondering if this is something Dropbox will ever fix?

Thanks for any insight!