Resolve a patch target's apks when the patch runs - #105
Open
JingMatrix wants to merge 1 commit into
Open
Conversation
A patch request records where its target's apks are, and then outlives that reading: it is edited on a configure screen, written to disk, re-entered after the process has been killed, and re-run by a retry. Where an installed app keeps its apks is the system's choice rather than this app's, and nothing holds that choice still across an update, a reinstall or an uninstall. A path recorded at one moment therefore describes the past, and reading it as a location fails with the files not being there at all. Those paths are treated as a name for the target instead. An installed target is resolved again as the job starts, so the report and the patch both work from where the app is now; a target the package manager no longer lists keeps what it had, and a note beside the input list says which of the two happened. Apks picked from storage are copies this app owns, which nothing outside it can move. A package the system cannot resolve is asked about once more, since one kept without its apks is not one that is gone, and the two need different answers from whoever reads the report. What was recorded and what was found are written to the log, where a report already carries them. An apk still absent after that is reported before the engine is entered, where the paths are known to be current and the absence is a fact about the app rather than about a record of it.
1 task
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.
A patch request records the apk paths of its target when the target is chosen, and then outlives that
reading: the request is edited on the configure screen, written to disk, kept for a day, re-entered
after the manager's process is killed, and re-run unchanged by a retry. Where an installed app keeps
its apks is the system's choice, and an update, a reinstall or an uninstall can leave a recorded path
pointing at nothing. The patch then fails inside the engine, on the source apk not existing.
Those paths are treated as a name for the target here rather than as its location. An installed
target is resolved again as the job starts, so the report and the patch both work from current paths,
and a retry resolves afresh. A package the system no longer resolves keeps what the request held, and
the log says whether it is uninstalled or only archived -- a distinction that reads identically from
a missing path alone. Apks picked from storage are copies this app owns and are left as they are. An
apk still absent after that is reported by name before the engine is entered, instead of surfacing as
the engine's own exception type.
Reported in #104. That report shows every apk of a split app missing while another installed app's
apk, read by the same process in the same instant, was present, so access is not the problem -- but
whether that app had moved or was no longer there cannot be recovered from it, and this change
assumes neither. It removes the dependency on a recorded path staying valid, and records enough to
tell the causes apart the next time one arrives.