We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.

Forum Discussion

warniiiz's avatar
warniiiz
Explorer | Level 4
7 years ago

Case-sensitivity of path_display with renamed parent folder

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.

  • Greg-DB's avatar
    Greg-DB
    Icon for Dropbox Staff rankDropbox Staff

    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's avatar
      warniiiz
      Explorer | Level 4
      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's avatar
        mmolledo
        Explorer | Level 3

        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.
        :( :( 

About Dropbox API Support & Feedback

Node avatar for Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

5,877 PostsLatest Activity: 6 hours ago
325 Following

If you need more help you can view your support options (expected response time for an email or 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!