App gets stuck on "Downloading database file"

[MadWalnut]

Describe the bug
During the last few weeks, #126 has started appearing multiple times per day to the point where the app pretty much became completely useless, as it would not open the database 80% of the time. So I decided to switch my cloud provider from Google Drive to Dropbox to see if it's any better. I have not run into #126 so far, but another bug appears very frequently while using Dropbox:

App stuck screenshot

KeePassium gets stuck around 50% of the times I try to open the database in Dropbox. It will just load very long (like 30-60 seconds and the cancel button does not work) and then quits with this error message:

Error screenshot

This is the error log:

0.000 (D) ChallengeResponseManager.swift:46 makeHandler(for:) Challenge-response is not used
0.002 (I) DatabaseManager.swift:171 _loadDatabase(dbRef:compositeKey:) Will load database
15.021 (D) Watchdog.swift:125 willResignActive() Going to background: App Lock engaged
15.103 (E) DatabaseLoader.swift:181 onDatabaseURLResolved(url:fileProvider:) Failed to open database document [error: Dropbox does not respond.]
15.206 (I) UnlockDatabaseVC.swift:567 setKeyFile(urlRef:) Key file set successfully
15.223 (E) UnlockDatabaseVC.swift:276 showErrorMessage(_:details:suggestion:haptics:) Cannot open database file
Dropbox does not respond.
15.225 (W) FileInfoReloader.swift:58 getInfo(for:update:completion:) Failed to get file info [reason: Dropbox does not respond.]
15.774 (D) Watchdog.swift:125 willResignActive() Going to background: App Lock engaged
24.718 (E) UnlockDatabaseVC.swift:166 didReceiveMemoryWarning() Received a memory warning

This might be related to #126 or #92. I did not post there, because the bug does not completely match, but there are parallels. All these file access issues seem to have appeared on iOS 14.

Access to Dropbox (and also Google Drive) through the Apple Files app works as expected.

Another thing I noticed that is probably not related, but still is an issue with Dropbox: KeePassium does not seem to respect filename casing (capitalization). My database is named "Passwords.kdbx", but KeePassium shows it as "passwords.kdbx". This does not happen when using Google Drive. Maybe this affects the Dropbox storage provider while opening the database? Seems unlikely because it does sometimes work, but I thought I'd better mention it.

To Reproduce
Steps to reproduce the behaviour:

1. Open app with Dropbox database.
2. See error (~50% chance).

User Information (please complete the following information):

• Device: iPhone XS
• OS: iOS 14.2
• App Version: v1.19.76

[keepassium]

Have you tried marking the database as "available offline" in Dropbox? (as suggested in #92)

Another thing I noticed that is probably not related, but still is an issue with Dropbox: KeePassium does not seem to respect filename casing (capitalization). My database is named "Passwords.kdbx", but KeePassium shows it as "passwords.kdbx".

KeePassium shows what Dropbox gives it. And Dropbox has a long-standing issue with capitalization on iOS.

[MadWalnut]

Have you tried marking the database as "available offline" in Dropbox? (as suggested in #92)

Yes. Then KeePassium gets stuck at "Contacting storage provider" instead of "Downloading database file":

Stuck while accessing "available offline" database

That has already been reported in #109, but in that issue only files stored in "On My iPhone" get this issue. But probably due to offline syncing it's the same bug.

KeePassium shows what Dropbox gives it. And Dropbox has a long-standing issue with capitalization on iOS.

Right, that explains it. Weird one on Dropbox' side.

[keepassium]

Yes, it is probably the same as #109. It's just some delays are expected for cloud storage, but timing out after 15 seconds is simply outrageous for a local file.

My hypothesis is that some other app or system service occupies&blocks all the file access queues. So KeePassium is waiting for a chance to get access to the database, but this never happens...

The question is what exactly occupies the file access layer.

• Do you have any photo backup app running in background? (Including Dropbox' own "Camera Uploads")
• A wild guess: are you logged in to your iCloud account? (system settings → your name → iCloud)
• Another wild guess: Do you have iCloud Drive enabled? (system settings → your name → iCloud → iCloud Drive)

[MadWalnut]

• Do you have any photo backup app running in background? (Including Dropbox' own "Camera Uploads")

Yes I have that enabled. I disabled it, restarted the phone (to make sure blocks are cleared) and could access KeePassium with no problem! Then I turned it back on, restarted again and it still works... Not sure if it really is due to the camera uploads or if just the restart fixed it. I will keep an eye on this and report back after I had more time to test. Now I have to wait for the issue to reappear.

• A wild guess: are you logged in to your iCloud account? (system settings → your name → iCloud)

You mean just generally logged into my Apple ID? Yes I am. I use iCloud for Backup.

• Another wild guess: Do you have iCloud Drive enabled? (system settings → your name → iCloud → iCloud Drive)

No, I have always had that completely disabled.

[keepassium]

Now I have to wait for the issue to reappear.

So, did it?

[MadWalnut]

Sorry, I stopped using KeePassium for now because especially #126 (but also this issue) happens multiple times a day and it's driving me crazy :/ I'm still happy to help though if you have anything to test or need more logs.

Anyway, I gave it another go just now and iOS storage manager did not disappoint: the issue appeared right away. Dropbox camera uploads have been disabled since my last post and yet I got stuck on "Downloading database file". I guess it's pretty safe to say it's not the camera uploads blocking something...

Restarting the whole device has a 100% success rate for me. Not really a practicable day-to-day-workaround though... Killing background apps (Dropbox, Apple Files, KeePassium etc.) on the other hand did not help at all.

I find it weird how nobody else seems to have this issue (or is just nobody reporting?), escpecially with such a popular cloud service like Dropbox. I really hope we are not chasing a ghost just because something weird is going on with my particular setup. But I honestly have no idea how one could mess-up a setup on a closed platform like iOS. So I guess here we are :D

[keepassium]

Thank you for the update! I believe #126 and this issue are related, so one can hold a solution for the other one. (And I understand these issues can make the app unusable...)

• Is your Dropbox PIN-protected, by any chance?
• Is Dropbox allowed to use cellular data connection? (both in Dropbox settings and in system settings → Mobile Data)

[MadWalnut]

• Is your Dropbox PIN-protected, by any chance?

No. Same for Google Drive (where #126 happens too).

• Is Dropbox allowed to use cellular data connection? (both in Dropbox settings and in system settings → Mobile Data)

Mobile Data is turned on. Just camera uploads are turned off on cellular. The issue appears on both WiFi and cellular. It also happens on my iPad, which does not have a cellular chip.

[keepassium]

Thanks! I am out of ideas at the moment... Once I have an insight, I'll be back.

[keepassium]

One year later…

• Did you happen to have a network drive/SMB server connected to the Files?
• Does the issue still happen?

[MadWalnut]

Yes I indeed had network drives connected to the Files app. However I do not own any Apple devices anymore, so I'm afraid I can't do any follow up tests anymore. Up until a few months ago I still had the issue, yes.

[keepassium]

@MadWalnut , thanks for the response!

Yes I indeed had network drives connected to the Files app.

Yep, practice shows that network drives in the Files app tend to make the whole file access layer unresponsive. Especially when device is online, but server is unreachable.

I guess it is safe to consider this is a duplicate of #109.

[keepassium]

For the record, there was a similar issue in v1.32, unrelated to SMB connections and caused by a race condition. Fixed in 662375a

[thanks for reminder, @nanayapro]