Repeated saving to Dropbox fails with "No such file"

[keepassium]

Description
When a Dropbox-stored database is opened in KeePassium, then edited and saved — the second saving attempt fails with the error "The file … couldn’t be opened because there is no such file."

How to reproduce
Steps to reproduce the behavior:

1. Open a database stored in Drobox
2. Add an entry, tap Done, observe the database is saved correctly.
3. Add another entry, tap Done
4. Observe an error alert: "The file … couldn’t be opened because there is no such file."

Expected behavior
The database should be saved without errors.

Environment:

• Device: iPhone 11 (and others)
• OS: iOS 15.7.7, 16.6, and others
• KeePassium version: 1.45.138
• Dropbox version: 340.2.2

Additional context
The issue started in early August 2023, seemingly after Dropbox update to v340.2.2. On device with Dropbox 336.2.2 the issue does not occur.

** Workaround **
The issue does not occur if the database is reloaded after each save. That is, the "open - edit - save - close - open" sequence can be repeated without triggering the error.

Alternatively, you can use the "Save as..." button in the error alert and still save the database to Dropbox. (Both workarounds are admittedly ugly...)

[keepassium]

Hmm, this is a tough one… I have tried many variations of the file writing parameters and found only one that seemingly solved the problem: removing file coordination. If the app simply writes to the file without any regard to other app, the database in Dropbox can be written several times without an issue. Not really a fix, but good enough for a quick patch.

As the patch was heading to the App Store, I discovered that file changes are indeed saved to the file, but that file never gets uploaded to Dropbox. Dropbox simply does not detect the file as modified, so all the changes remain in device's local cache. So the problem actually became worse.

Sorry, folks. Patch release postponed, we go back to square one…

[keepassium]

Finally found out the cause and fixed the issue. Apparently, new Dropbox fails to handle NSFileCoordinator.coordinate() calls that include both the reading and writing intent simultaneously. This is likely their bug but it can be solved on KeePassium's side, too.

The fix is coming with the next update.

[LVladymyr]

Looks solved case with create-save-edit-save record on v1.46.140 beta.

[keepassium]

@LVladymyr, thank you for confirming.