Things look fine in the site, but when I download a zip many folders come as sort of duplicates, one with the original name and one with the name converted to lowercase. As far as I can tell, newer files tend to end up in these all-lowercase folders, but there are exceptions.

As I'm using Linux, folders get created with both names, and in my particular case (thousands of files and folders, where the case really matters) I don't have a good workaround.

Again, while I could understand that preserving the case is not something Dropbox might want to do (as most users are probably on case-insensitive file systems), there's probably a bug somewhere causing this mix. Or maybe this is the design, but I wonder if there's a workaround or something I can do to get zips with non-duplicated, case-preserved folders. And why this difference between the site and the zip?

Thanks

Thanks for keeping us in the loop here ciobi. 

Can you post some screenshots showing the issue so we can have a visual too? 

If possible, try doing it with a sample folder for testing purposes to avoid exposing any of your personal information here on our Community. 

Thanks! 

Thanks for keeping us in the loop here . 

Can you post some screenshots showing the issue so we can have a visual too? 

If possible, try doing it with a sample folder for testing purposes to avoid exposing any of your personal information here on our Community. 

Thanks! 

Hi,

I created a copy of a problematic subfolder in a different place, and that downloads OK.

I also removed temporarily the problematic folder, and when I put it back after a few days, it still showed the issue with some of its subfolders having both lowercase and case-preserved variants. The same if I download just one subfolder.

The tools that see these issues in Linux are: Ark, 7zip, Krusader.

In Windows, 7zip only shows the mixed-case folder names, though, which is the expected behaviour.

Thanks

Hi,

I created a copy of a problematic subfolder in a different place, and that downloads OK.

I also removed temporarily the problematic folder, and when I put it back after a few days, it still showed the issue with some of its subfolders having both lowercase and case-preserved variants. The same if I download just one subfolder.

The tools that see these issues in Linux are: Ark, 7zip, Krusader.

In Windows, 7zip only shows the mixed-case folder names, though, which is the expected behaviour.

Thanks

Hi ciobi,

This bug affects only directory trees existing for a while. A new (relatively) directory tree isn't getting affected. So, a workaround could be moving affected trees in new directory, which serves as a alternative root. Let say, you have folders 'Folder1', 'Folder2', 'Folder3' and 'Folder4' inside your Dropbox account. Discussed trouble appear for 'Folder2' and 'Folder3'. You can create in your account a folder 'AltRoot', for example, and move 'Folder2' and 'Folder3' into just created folder. After that you should be able download compressed folders without issues (properly formatted), either the moved folder itself of others contained inside.

Hope this helps to some extent.

Hi Walter,

The issue comes from the fact that for some folders when declared in the zip file they appear with correct capitalization, but when used as part of path to some file inside, they appear entirely lower case. Capitalization mismatch confuses some applications. You wouldn't be able reproduce that because new directory trees aren't affected. I tried to make a list of steps to reproduce the situation for you, but unsuccessfully. If I have to bet, some system upgrade of the web interface seems done wrong. Probably incompatibility with some previously used format (or least not full compatibility). I'm not sure actually. From technical point of view, it isn't mandatory letter capitalizations of directory definitions to match their usage in file paths. This is not clearly defined in ZIP specification, unfortunately. Anyway, all native zippers on either Mac, Linux or Windows, when create a directory trees in a zip file, capitalizations for directory definitions match to those used file path! In some specific cases this is NOT true for the zip algorithm used in Dropbox Web. This is strange, at least, although not technically bug! All applications relying on 'zlib' to access the files, could fall in confusion.

The good in all of this is that Dropbox applications, either desktop or mobile aren't affected, only Dropbox website behave stupid in such situation.

For additional clarity (let's hope) follows a picture of binary view of zipped folder, named \"GolfP\" downloaded from the Dropbox site:

As could be seen directory definition uses proper capitalization, but when used as a part from the path to file \"SamChip.h\" all letters are lowercase. The same file produce following view in an archiver:

As could be seen, actual tree starts with lowercase name folder. The properly named folder is empty!

Hope this could gives some directions. Not perfect, but... let's hope experts (at least more experienced) from development team will get right direction.

Hi ,

This bug affects only directory trees existing for a while. A new (relatively) directory tree isn't getting affected. So, a workaround could be moving affected trees in new directory, which serves as a alternative root. Let say, you have folders 'Folder1', 'Folder2', 'Folder3' and 'Folder4' inside your Dropbox account. Discussed trouble appear for 'Folder2' and 'Folder3'. You can create in your account a folder 'AltRoot', for example, and move 'Folder2' and 'Folder3' into just created folder. After that you should be able download compressed folders without issues (properly formatted), either the moved folder itself of others contained inside.

Hope this helps to some extent.

Hi ,

The issue comes from the fact that for some folders when declared in the zip file they appear with correct capitalization, but when used as part of path to some file inside, they appear entirely lower case. Capitalization mismatch confuses some applications. You wouldn't be able reproduce that because new directory trees aren't affected. I tried to make a list of steps to reproduce the situation for you, but unsuccessfully. If I have to bet, some system upgrade of the web interface seems done wrong. Probably incompatibility with some previously used format (or least not full compatibility). I'm not sure actually. From technical point of view, it isn't mandatory letter capitalizations of directory definitions to match their usage in file paths. This is not clearly defined in ZIP specification, unfortunately. Anyway, all native zippers on either Mac, Linux or Windows, when create a directory trees in a zip file, capitalizations for directory definitions match to those used file path! In some specific cases this is NOT true for the zip algorithm used in Dropbox Web. This is strange, at least, although not technically bug! All applications relying on 'zlib' to access the files, could fall in confusion.

The good in all of this is that Dropbox applications, either desktop or mobile aren't affected, only Dropbox website behave stupid in such situation.

For additional clarity (let's hope) follows a picture of binary view of zipped folder, named \"GolfP\" downloaded from the Dropbox site:

As could be seen directory definition uses proper capitalization, but when used as a part from the path to file \"SamChip.h\" all letters are lowercase. The same file produce following view in an archiver:

As could be seen, actual tree starts with lowercase name folder. The properly named folder is empty!

Hope this could gives some directions. Not perfect, but... let's hope experts (at least more experienced) from development team will get right direction.

Hi Здравко,

Indeed, renaming the root folder fixed the problem, and indeed when I look at the binary content of the .zip file I can see both lowercase and preserved-case names.

Perhaps the specs aren't clear enough, but I still don't see a good reason not to just preserve the case. So I'd say this is still a bug, with a workaround.

Well, thanks!

Hi ,

Indeed, renaming the root folder fixed the problem, and indeed when I look at the binary content of the .zip file I can see both lowercase and preserved-case names.

Perhaps the specs aren't clear enough, but I still don't see a good reason not to just preserve the case. So I'd say this is still a bug, with a workaround.

Well, thanks!