Repository navigation
fix(fnos): resolve data directory dynamically instead of hardcoding paths - #1394
Open
lovelitchi wants to merge 5 commits into
Open
lovelitchi wants to merge 5 commits into
lovelitchi wants to merge 5 commits into
Conversation
The Docker package hardcoded /var/apps/octop/share/octop/data as the data
directory, but fnOS devices may install to different paths (e.g.
/vol1/@appcenter/octop). Use TRIM_DATA_SHARE_PATHS from fnOS with a
TRIM_APPDEST fallback, matching the native package pattern.
This change updates docker-compose.yaml to use ${OCTOP_DATA_DIR} with
a fallback to the original hardcoded path.
Update data directory resolution logic to handle different app install roots and avoid permission errors.
Update data directory resolution logic to handle different app install roots and improve compatibility.
Dynamically resolve the data directory for uninstallation based on TRIM_DATA_SHARE_PATHS or TRIM_APPDEST.
Updated the data directory resolution logic to handle different installation paths and ensure compatibility with various devices. Added synchronization of OCTOP_DATA_DIR in the .env file.
This branch has not been deployed
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.
Summary
The fnOS Docker package hardcodes the data directory as
/var/apps/octop/share/octop/data(or/vol1/@appshare/octop/datain uninstall). On devices where the app install root is on a different volume (e.g./vol1/@appcenter/octop), the hardcoded path fails with permission errors because the actual data-share directory is elsewhere.This PR resolves the data directory dynamically — matching the logic already used by the native fnOS package — by reading
TRIM_DATA_SHARE_PATHS(provided by fnOS at install time) and falling back to deriving the path fromTRIM_APPDEST.Changes
${OCTOP_DATA_DIR:-/var/apps/octop/share/octop/data}so the host path is driven by an env var written at install/upgrade time.DATA_DIRwith dynamic resolution fromTRIM_DATA_SHARE_PATHS/TRIM_APPDEST.DATA_DIRresolution + writesOCTOP_DATA_DIRto.envso docker-compose picks it up./vol1/@appshare/octop/datawith the same dynamic resolution.DATA_DIRresolution + callsoctop_env_setto keepOCTOP_DATA_DIRin.envin sync across upgrades.Test plan
TRIM_APPDESTpoints to a non-default volume and verify the data directory is created at the correct location.OCTOP_DATA_DIRis written to.envand the volume mount resolves correctly.