macOS: import the official app's store into the fork build (#39)#40
Merged
Conversation
The fork ships a ".staging" macOS build that installs BESIDE the official app, so its SQLite store lives at the plain ~/Library/Application Support/OpenWhoop, not the official app's sandbox container. A user moving from official NOOP to the fork therefore saw an empty database — their data was never deleted, just orphaned in ~/Library/Containers/com.noopapp.noop/Data/…/OpenWhoop (#39). Keep the .staging identity (beside-install intent) and instead COPY the official container store into the fork's store on first launch (our store still empty). COPY, never move — the official app may still be installed and using it. The distributed build is unsigned, so it isn't sandboxed and can read the sibling container; if a sandbox is unexpectedly engaged we bail rather than guess. Reuses the same empty-destination guard as migrateLegacyStoreIfNeeded, so it never clobbers a fork user who already has data. Fixes #39.
ryanbr
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What #39 reported
Installing 8.3.2 on macOS over 8.2.x opens an empty database — all data appears lost. Old path
~/Library/Containers/com.noopapp.noop/Data/…/OpenWhoop; new path~/Library/Application Support/OpenWhoop.Root cause
The v8.3.0
719477a8"NOOP Staging identity" rename set the macOS bundle ID tocom.noopapp.noop.stagingso the fork installs beside the official app. ButStorePaths.macOSProductionContainerAppSupportpins the store to the sandbox container only for the exact production IDcom.noopapp.noop; under.stagingit uses the plain~/Library/Application Support/OpenWhoop, and the existingmigrateLegacyStoreIfNeeded(gated oncontainerAppSupport != appSupport) never runs. So a user coming from the official app reads a fresh, empty directory.The data was never deleted — it's still in the official app's container.
Fix — keep
.staging, copy the official store inRather than flip the bundle ID (which would make the fork replace the official app), keep the beside-install
.stagingidentity and copy the officialcom.noopapp.noopcontainer store into the fork's store on first launch:destinationHasDataguard as the existing migration), so it never clobbers a fork user who already has data.CODE_SIGNING_ALLOWED=NOinfork-release.yml), so it isn't sandboxed and can read the sibling container. If a sandbox is ever unexpectedly engaged,homeDirectoryForCurrentUserpoints inside our own container and the official store is unreachable → we bail rather than guess.Who is affected, and what happens
No bundle-ID / identity change; the fork stays "NOOP Staging" beside the official app. Swift-only change; CI build dispatched to verify (can't compile Swift locally).
Fixes #39.