Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
Hello,
I am using the Python dropbox SDK and I encounter a problem when modifying the case of directories that have already been declared (same name but different case) in the past.
For example, going from a dir:
/testdir/NewTest
To the same renamed one (only the case is modified):
/testdir/nEWtEST
After this kind of renaming, when listing the files with dbx.files_list_folder, the FolderMetadata of the renamed folder is OK (attribute path_display is correct), but the FileMetadata (and FolderMetada if any) of the subfiles (and subdirectories) are NOK: attribute path_display keep writing the name of the parent folder (the one that has been renamed) with the wrong case.
For example:
/testdir/NewTest/subfile.txt
Instead of:
/testdir/nEWtEST/subfile.txt
Complete code to reproduce the problem:
import dropbox dbx = dropbox.Dropbox(TOKEN) # create test dir path_1 = '/testdir' dbx.files_create_folder(path_1) # create a subdir and upload a file in this sub dir path_2 = '/testdir/NewTest' dbx.files_create_folder(path_2) dbx_file_path = '/testdir/NewTest/file.txt' with open(local_file_path, 'rb') as local_file: dbx.files_upload(f=local_file.read(), path=dbx_file_path) # list content of test dir lfr = dbx.files_list_folder(path=path_1, recursive=True) print(lfr.entries) # Gives 3 entries with correct spelling of path_display: # FolderMetadata(name='testdir', path_lower='/testdir', path_display='/testdir'), # FolderMetadata(name='NewTest', path_lower='/testdir/newtest', path_display='/testdir/NewTest'), # FileMetadata(name='file.txt', rev='73d511ef48f', size=8, path_lower='/testdir/newtest/file.txt', path_display='/testdir/NewTest/file.txt') # Then delete and recreate subdir under a new name, and re-upload file dbx.files_delete_v2(path=path_2) renamed_path_2 = '/testdir/nEWtEST' dbx_file_path2 = '/testdir/nEWtEST/file2.txt' dbx.files_create_folder(renamed_path_2) with open(local_file_path, 'rb') as local_file: dbx.files_upload(f=local_file.read(), path=dbx_file_path2) # list content of test dir lfr = dbx.files_list_folder(path=path_1, recursive=True) print(lfr.entries) # Gives 3 entries with correct spelling of path_display for the FolderMetadata but not for the sub FileMetadata: # FolderMetadata(name='testdir', path_lower='/testdir', path_display='/testdir'), # FolderMetadata(name='NewTest', path_lower='/testdir/newtest', path_display='/testdir/nEWtEST'), # FileMetadata(name='file2.txt', rev='741511ef48f', size=8, path_lower='/testdir/newtest/file2.txt', path_display='/testdir/NewTest/file2.txt') # Try the same with double rename subdir with uppercase renamed_path_aux = '/testdir/NEWTEST2' renamed_path_2 = '/testdir/NEWTEST' dbx.files_move_v2(from_path=path_2, to_path=renamed_path_aux) dbx.files_move_v2(from_path=renamed_path_aux, to_path=renamed_path_2) # list content of test dir lfr = dbx.files_list_folder(path=path_1, recursive=True) print(lfr.entries) # Gives 3 entries with incorrect spelling (still the same problem): # FolderMetadata(name='testdir', path_lower='/testdir', path_display='/testdir'), # FolderMetadata(name='NewTest', path_lower='/testdir/newtest', path_display='/testdir/NEWTEST'), # FileMetadata(name='file2.txt', rev='749511ef48f', size=8, path_lower='/testdir/newtest/file2.txt', path_display='/testdir/NewTest/file2.txt')
PS: I read after typing that the problem was known and assumed for API v1. But with API v2, it seems that the problem does not concern anymore the whole attribute path_display, but only the parent folder that have been renamed (as we can see in the above first list, where the case sensitivity works well for parent folder : path_display='/testdir/NewTest/file2.txt')
Thank you for your support.
Are you planning to correct this behavior?
Clément W.
Thanks for writing this up! Unfortunately, this behavior is sometimes expected. Even in path_display
, the original casing isn't always available for all components. There's a note about this in the API v2 documentation, under "Case insensitivity":
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.
We understand this is non-ideal of course, and I'll forward this on to the team as feedback, but I can't make any promises as to if or when this might be improved in the future.
Thanks for writing this up! Unfortunately, this behavior is sometimes expected. Even in path_display
, the original casing isn't always available for all components. There's a note about this in the API v2 documentation, under "Case insensitivity":
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.
We understand this is non-ideal of course, and I'll forward this on to the team as feedback, but I can't make any promises as to if or when this might be improved in the future.
I'm having the same problem.. it's difficult to imagine such an error when it's so visible and unusable getting a path that is not the correct one..
I'm looking forward to a good solution because I thought about doing the same as you @warnizz... but I'm managing hundreds of files...
will reduce performance so much that it's not worth it.
😞 😞
Hi there!
If you need more help you can view your support options (expected response time for a ticket is 24 hours), or contact us on X or Facebook.
For more info on available support options for your Dropbox plan, see this article.
If you found the answer to your question in this Community thread, please 'like' the post to say thanks and to let us know it was useful!