Skip to content

File Provider writes from third-party apps (KeePassium) not syncing back to Filen after latest iOS app update #1

Description

@sailor-o

iOS version: 26.5.2
Filen app version: 4.0.8
Third-party app involved: KeePassium (KDBX password manager)
Description:
I access a .kdbx file stored in Filen through the Apple Files app’s Filen provider, opened from within KeePassium. This worked correctly before the latest Filen app update. After updating to the new redesigned Filen app, changes I make to the KDBX file inside KeePassium (e.g. adding a new password entry, saving) are no longer written back to the copy stored on Filen.
Steps to reproduce:
1. Open the .kdbx file located in Filen via the Files app / Filen file provider, from within KeePassium.
2. Add a new entry (or edit an existing one) and save inside KeePassium.
3. Wait (tested waiting several minutes) and manually trigger a refresh in Files app / Filen.
4. Re-open the same file (from Filen web, another device, or by force-closing and reopening) — the new change is missing. The file on Filen’s side was never modified.
Expected behavior:
Saving the file in KeePassium should trigger Filen’s File Provider Extension modifyItem callback and upload the new file contents to Filen’s servers, the same way it did before the update.
Actual behavior:
No error is shown anywhere. The write silently does not propagate — no upload indicator, no sync icon change, nothing. Data loss risk since this is a password database and new entries are simply lost.
What I’ve already tried:
• Keeping the Filen app open in the foreground while saving in KeePassium
• Manually forcing “Download Now” on the file in Files app before editing
• Clearing the File Provider cache in Filen settings
• Reinstalling the Filen app entirely
None of these resolved it.
Additional notes:
This seems related to the file provider / third-party app integration issues Filen mentioned in the “Filen Mobile: Your Feedback & Our Response” post (Dec 2025) about third-party app interoperability with the file provider still being rough. Given this affects a password database, silent write failures are a serious data-integrity concern — a visible error or failed-sync indicator would at least prevent silent data loss even before a full fix is available.
Happy to provide device logs / sysdiagnose if needed.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions