Keepass2android: Filename made lowercase on save.

[tERyceNzAchE]

My database "Password Vault.kdbx" is saved on Dropbox. When edited using keepass2android a backup is saved on Dropbox as "Password Vault.old.kdbx" but the current database is renamed to "password vault.kdbx" (lowercase).

Database filename should not be modified by the App.

[puchrojo]

Same problem. I try, but I can't find the code that make a lowercase.

[gronostajo]

Same here. The path on unlock screen is dropbox://portable/something.kdbx, while the actual path in Dropbox is Portable/Something.kdbx. This is a PITA if you use the same file on Linux, because the filesystem is case-sensitive and KeePass can't find the file anymore until you rename it back.

[serovar]

It is absurd that this bug still exists.

[mauromol]

I confirm this problem, after I made a change to my database with KP2A, the database file name on Dropbox was changed to lowercase...

[codeThatThinks]

I've also been having this issue now that I've been using Keepass2Android to update some passwords. In the past I've always edited the database on my computer, so this is my first time encountering this.

A quick search looks like #1121 is a duplicate of this.

It appears IOConnectionInfo is used to store path information for the database, so my initial thought was that maybe there is something funky going on in there. However, after playing around with the debug log, this issue only occurs when using Dropbox for storage. I tried saving to internal storage as well as using SFTP and in both cases the path isn't changed to lowercase. So the issue is in the Dropbox-specific code...

I noticed in the debug logs that the path is changed to lowercase immediately after selecting the database in the file chooser. DropboxV2Storage handles that, and with a closer look I found line 384 of DropboxV2Storage.java:

        fileEntry.path = getProtocolId()+"://"+ e.getPathLower();

This is in convertToFileEntry() and is called in order to convert the path that dropbox returns into a FileEntry object so that it can be displayed in the file chooser. getPathLower() is a method in the Metadata class (part of the Dropbox V2 Java SDK). Unfortunately, there doesn't seem to be a method to return a non-lowercased version of the path besides getPathDisplay(), which is supposed to only be used for display purposes -- not sure what the implications would be if we used that.

I found this blurb about case-insensitivity in Dropbox's API documentation:

__Path case insensitivity__

Like in Dropbox itself, paths in the Dropbox API are case-insensitive, meaning that /A/B/c.txt is the same file as /a/b/C.txt and is the same file as /a/B/c.txt.

This can cause problems for apps that store file metadata from users in case-sensitive databases (such as SQLite or Postgres). Case insensitive collations should be used when storing Dropbox path metadata in such databases. Alternatively, developers need to make sure their query operators are explicitly case insensitive.

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 path components, it can get it from the Metadata.name or last path component of each relevant Metadata.path_display entry.

Looks like there could potentially be a solution using part of getName() or getPathDisplay() or something.

[mauromol]

It's unbelievable that Dropbox makes such a simple non-problem so hard to deal with... All Unix filesystems are case sensitive by default... Even Windows, although having a case-insensitive file system, never changes the case of paths and file names arbitrarily when a file is queried or handled...
Anyway, the problem is really annoying and leads to actual problems when the same database is also shared on a Linux/Unix system, because it indeed changes the database file name. On the other hand, KP2A is the first application I see that leads to such a problem.

[codeThatThinks]

@mauromol You bring up a good point, that _none of the other Dropbox-enabled apps have this issue_. I did some testing and I couldn't get any other app to reproduce this behavior.

Which brings me back to paths ... are case-insensitive, meaning that /A/B/c.txt is the same file as /a/b/C.txt. If this truly the case, why would giving the API a lowercase path on upload cause an issue? In Dropbox's backend it should be the same file object.

I wonder if this behavior is actually a bug in the Dropbox Java SDK?