Skip to content

Keep the database in the File Provider state directory (fix "signed out" Finder)#20

Merged
alexmodrono merged 1 commit into
mainfrom
fix/db-back-to-state-dir
Jun 3, 2026
Merged

Keep the database in the File Provider state directory (fix "signed out" Finder)#20
alexmodrono merged 1 commit into
mainfrom
fix/db-back-to-state-dir

Conversation

@alexmodrono

Copy link
Copy Markdown
Owner

Summary

After 0.2.0 relocated the canonical database to the App Group container, Finder showed the domain as "signed out" and "Open in Finder" did nothing. The live extension log shows why:

libsqlite3: Failed to open '…/group.es.amodrono.foodle/…/foodle.db' for read/write (Operation not permitted)
[Extension] Database resolution failed: Could not open database: authorization denied

A File Provider extension's sandbox cannot open files in the App Group container (the app can, which is why the app worked). So the extension couldn't open the DB at all → not-authenticated → "signed out". This is why the original design kept the DB in the File Provider state directory — the one place the extension can read/write.

Fix

  • Revert the canonical database to the File Provider state directory (restores the proven path the extension can access).
  • Fix the original "disk I/O error" a different way: before a domain reset deletes the state directory (and its database), point the app's live handle at the App Group bootstrap database, which the app can write. A sync during the reset — or after a failed re-seed — then writes to a valid handle instead of a deleted file.

Keeps the data-protection keychain change and What's New-per-build from the prior PRs.

Verification

Root cause is proven from the production extension log (EPERM on the App Group DB). The fix restores the original state-directory code, under which the extension demonstrably worked before. Local end-to-end Nightly verification was blocked by a rebuilt-extension being wedged in pluginkit (-2001), which a clean notarized install does not hit.

A File Provider extension's sandbox cannot open files in the App Group container (open() returns EPERM), so moving the canonical database there left the extension unable to open it: it reported not-authenticated and Finder showed the domain as "signed out". The extension can only write inside its own domain state directory, which is why the database belongs there.

Restore the state-directory database (shared by the app and extension) and fix the original "disk I/O error" differently: before removing the File Provider domain — which deletes the state directory and its database — point the app's live handle at the App Group bootstrap database, which the app can write. A sync that runs during the reset, or after a failed re-seed, then writes to a valid handle instead of a deleted file. After re-adding the domain the shared database is re-seeded and adopted again.
@alexmodrono alexmodrono merged commit 3019a51 into main Jun 3, 2026
1 check passed
@alexmodrono alexmodrono deleted the fix/db-back-to-state-dir branch June 3, 2026 13:12
@github-actions

github-actions Bot commented Jun 3, 2026

Copy link
Copy Markdown

Nightly Build

Download Findle Nightly (unsigned)

Built from 8b173c8.

Important

This build is unsigned. macOS will block it on first launch. To open it:

  1. Try to open the app normally — macOS will show a warning and refuse.
  2. Go to System Settings → Privacy & Security, scroll down, and click Open Anyway.
  3. The File Provider extension requires code signing and won't work in this build.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant