Child Item

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

I'm traversing a folder hierarchy and have come across a strange anomaly in the letter case of one of my folders.

When I call listFolder to get the hierarchy of my folders, everything seems normal until it gets down to the third level.

For example, when I fetch the 2nd level in the hierarchy, I get the correct case for all my folders:

DBFileInfo(path='/Share/Attachments', isFolder=YES, modified=2015-02-02 10:43:24 +0000, size=0, thumbExists=NO, icon=folder),
DBFileInfo(path='/Share/Exports', isFolder=YES, modified=2015-02-02 10:43:55 +0000, size=0, thumbExists=NO, icon=folder),
DBFileInfo(path='/Share/Imports', isFolder=YES, modified=2015-02-02 10:43:55 +0000, size=0, thumbExists=NO, icon=folder)

But when I traverse into the /Share/Attachments folder (the 3rd level) and call listFolder again, this is what I get:

DBFileInfo(path='/share/Attachments/1EA9CC59-D0A8-4F82-8054-12DA1DC129C8', isFolder=YES, modified=2015-02-02 10:43:24 +0000, size=0, thumbExists=NO, icon=folder),

1EA9CC59-D0A8-4F82-8054-12DA1DC129C8 is just another level of folders. There are also files at this level too and it has the same issue.

DBFileInfo(path='/share/Attachments/20110131 Bloomberg HP.pdf', isFolder=NO, modified=1979-12-31 07:00:00 +0000, size=868025, thumbExists=NO, icon=page_white_acrobat),

If you notice, "/Share" is what it should be, but it's coming in as "/share" with a lowercase "s" when I fetch the 3rd level of items.

I'm simply calling this code:

NSArray* files = [fileSystem listFolder:path error:outError];

Where "path" = "/Share/Attachments"

Is this a bug on the Dropbox side or something wrong that I'm doing?

It may seem like a small thing, but I'm doing some string searching that's case sensitive and it's throwing off my code. I feel like I'm going to have to add a special case for this in code which will set the case back to "/Share" instead of "/share".

Find more posts tagged with

API

Abuse

Comments

Greg-DB

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.

Brendan D.

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

Brendan D.

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?

Brendan D.

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)

Brendan D.

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?

Greg-DB

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

Brendan D.

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.

Greg-DB

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.

Brendan D.

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.

Behroz S.

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!

Greg-DB

Unfortunately I don't have an update on if or when we'll be able to improve this on our side. Sorry I don't have anything better to share!

Steve M.

This specific thread is about the Sync API, which is deprecated, so we won't be making changes to it.

More generally, /delta (API v1) and /files/list_folder (API v2) behave similarly in that only the last path segment is "correctly" cased (according to the current casing of the file). There are no immediate plans to change that, so my advice is to treat the Dropbox API as case-insensitive, since it is.

For the scenario raised here, of trying to locate files on the local file system, the only good way to do this is to maintain your own mapping of lowercased paths to cased paths in the local file system. Because Dropbox itself is case insensitive, if we returned you a fully cased path, it may still not match the local file system. E.g. you wrote a file called Hello.txt and uploaded it to Dropbox as Hello.txt. The user then renamed it to HELLO.TXT. Now if the API told you the path was HELLO.TXT, you wouldn't be able to find the file on the local file system, where no such file exists. If instead, your app kept track of "Hello.txt is the local path for /hello.txt in Dropbox," there would be no such problem.

So although we may revisit over time returning different information about the current casing of a file path in Dropbox, the fact that Dropbox itself is case-insensitive means that your app will need to maintain its own mapping when dealing with something like a case-sensitive file system.

testaccountprim

Actually i have an sync app for dropbox api. When i put request for a folder named TEST, it replies with the content of folder named test ...(i know dropbox is case insensitive).but i need to resolve...either u have options ? or i have to handle this?

Greg-DB

Hi "testaccountprimary", this is an old thread about the Sync SDK in particular. It's unclear if that's what you're referring to, so please open a new thread with additional details so we can help you without spamming the other people on this thread. Thanks!