Case-sensitivity of path_display with renamed parent folder

[warniiiz]

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.

[Greg-DB · Accepted solution]

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.

[warniiiz]

Thanks for your answer. I implemented the non-ideal method, looking recursively at each parent's metadata, to get the full path with correct case-sensitivity. It's not very efficient but it will do the job. Looking forward to see new improvements in the API 😉

[mmolledo]

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.
😞 😞